Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

2015-10-24 Thread Gary Kotton 
+1

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Saturday, October 24, 2015 at 6:38 AM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

Hokkaido (北海道 品川インターシティー店)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Not able to launch based VM due to nova-network service.

2015-10-24 Thread Rahul Arora 
Hi Team,

I am working on ICEHOUSE release of Openstack.*I am able to launch VM using
KVM/QEMU utility.*

Now i *want to launch LXC based VM* using the same release.

But I am getting below error while launching LXC based VM.These errors are
in *nova-neutron service.*

self._get_networks_by_uuids(context, network_uuids)\n', '  File
"/usr/lib/python2.7/site-packages/nova/network/manager.py", line 1824, in
_get_networks_by_uuids\ncontext, network_uuids, project_only=True)\n',
'  File "/usr/lib/python2.7/site-packages/nova/objects/base.py", line 110,
in wrapper\nargs, kwargs)\n', '  File
"/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 425, in
object_class_action\nobjver=objver, args=args, kwargs=kwargs)\n', '
File "/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py", line
150, in call\nwait_for_reply=True, timeout=timeout)\n', '  File
"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py", line 90, in
_send\ntimeout=timeout)\n', '  File
"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py",
line 412, in send\nreturn self._send(target, ctxt, message,
wait_for_reply, timeout)\n', '  File
"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py",
line 405, in _send\nraise result\n', 'NoNetworksFound_Remote: No
networks defined.\nTraceback (most recent call last):\n\n  File
"/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 597, in
_object_dispatch\nreturn getattr(target, method)(context, *args,
**kwargs)\n\n  File
"/usr/lib/python2.7/site-packages/nova/objects/base.py", line 112, in
wrapper\nresult = fn(cls, context, *args, **kwargs)\n\n  File
"/usr/lib/python2.7/site-packages/nova/objects/network.py", line 183, in
get_by_uuids\nproject_only)\n\n  File
"/usr/lib/python2.7/site-packages/nova/db/api.py", line 965, in
network_get_all_by_uuids\nproject_only=project_only)\n\n  File
"/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 164, in
wrapper\nreturn f(*args, **kwargs)\n\n  File
"/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 2582, in
network_get_all_by_uuids\nraise
exception.NoNetworksFound()\n\nNoNetworksFound: No networks defined.\n\n']

*Details of error.*
=

When i am creating network for the LXC VM.I am able to see the same network
using *neutron net-list* command,But i think this same network nova is not
able to access that's why i do *nova net-list* it shows nothing(no
network).Due to this,above error is coming.

Below are my nova and neutron configuration files.

*1. NOVA CONF*

[DEFAULT]
firewall_driver = nova.virt.firewall.NoopFirewallDriver
compute_driver = libvirt.LibvirtDriver
libvirt_cpu_mode = host-model
default_floating_pool = public
fixed_range =
force_dhcp_release = True
dhcpbridge_flagfile = /etc/nova/nova.conf
compute_scheduler_driver = nova.scheduler.filter_scheduler.FilterScheduler
rootwrap_config = /etc/nova/rootwrap.conf
api_paste_config = /etc/nova/api-paste.ini
allow_resize_to_same_host = true
auth_strategy = keystone
instances_path = /etc/nova/instances
debug = False
verbose = True
my_ip = 192.168.2.99
glance_host = 192.168.2.99
lock_path = /var/lock/nova/
libvirt_images_type = default

[libvirt]
virt_type = lxc


vnc_enabled = False
vncserver_listen =
novncproxy_base_url = http://:6080/vnc_auto.html
vncserver_proxyclient_address =

flat_interface = eth0
flat_network_bridge = br1
vlan_interface = eth0
public_interface = br1
network_manager = nova.network.manager.FlatDHCPManager
fixed_range =
force_dhcp_release = False
dhcpbridge = /usr/bin/nova-dhcpbridge

sql_connection = mysql://nova:NOVA_DBPASS@192.168.2.99/nova

rpc_backend = rabbit
rabbit_host = 192.168.2.99
rabbit_port = 5672

neutron_url =  http://192.168.2.99:9696
network_api_class = nova.network.neutronv2.api.API
security_group_api = neutron
neutron_auth_strategy = keystone
neutron_admin_tenant_name = service
neutron_admin_username = neutron
neutron_admin_password = NEUTRON_PASS
neutron_admin_auth_url = http://192.168.2.99:35357/v2.0/
linuxnet_interface_driver = nova.network.NoopFirewallDriver

vif_plugging_timeout = 10
vif_plugging_is_fatal = False

instance_usage_audit=True
instance_usage_audit_period = hour
notify_on_state_change = vm_and_task_state
notification_driver = nova.openstack.common.notifier.rpc_notifier

libvirt_images_rbd_pool = cinder-volumes
libvirt_images_rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_user = cinder-volume

service_neutron_metadata_proxy = true
neutron_metadata_proxy_shared_secret = ADMIN_PASS

[spice]
agent_enabled = True
enabled = True
html5proxy_base_url = http://:6082/spice_auto.html
keymap = en-us
server_listen =
server_proxyclient_address =

auth_strategy = keystone

[keystone_authtoken]
auth_uri = http://192.168.2.99:5000
auth_host = 192.168.2.99
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = nova
admin_password = NOVA_PASS


*2. NEUTRON CONF*

[DEFAULT]
state_path =

[openstack-dev] User Survey Results - October 2015

2015-10-24 Thread Tom Fifield 

Hi everyone,

Working with the user committee, we run a survey of users every six 
months. We are pleased to share the results of the latest survey, 
conducted in September.


Each survey is meant to provide a sample representation of OpenStack 
users and deployment profiles, with the goals to identify challenges and 
help inform developers planning the next release, help other users 
understand technology decisions made by their peers and help the 
ecosystem better understand the user profile and needs.



You can download the full report at:

 http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf


This would not be possible without the efforts of users and application 
developers to fill out the survey, and our entire community to help 
shape it. We hope this data and feedback will be a good resource heading 
into the Tokyo summit planning sessions and discussions




Thank you for all of your support and input, and see you at the summit!




Regards,




Tom, on behalf of the User Committee and Foundation Team


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova] [cinder] Mitaka summit working session: Resource Federation for an Open Cloud

2015-10-24 Thread Mike Perez 
On 12:27 Oct 19, George Silvis, III wrote:



> Although all of our changes are to Nova, the changes have implications
> for Cinder and Keystone as well.  So, with the help of the Nova team, we
> are in the process of organizing a cross-project session at the Mitaka
> design summit.  We're especially looking for Nova, Cinder, and Keystone
> developers to attend and give feedback.

I will definitely be there for the Cinder side.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] meeting place for event Monday night in Tokyo ...

2015-10-24 Thread Mike Perez 
On 15:54 Oct 21, Jay S. Bryant wrote:



> Not sure where the evening will take us, but we are planning to meet
> by registration at the Convention Center.  Looking at the map, if I
> am reading it properly, in front of the Huawei Community Lounge on
> the first floor looks like a good place to meet that is right near
> registration.  So, lets go for that.  :-)

I know a place with local craft beer and pizza. The only time this week you'll
probably have it in Tokyo with the other festivities happening.

venue: http://bairdbeer.com/en/tap/nakameguro.html
map: https://goo.gl/maps/umqvsjPag3S2

I delegate someone to make reservations for 15 people.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

2015-10-24 Thread Vikram Choudhary 
Great getting this arranged Akhiro!
On Oct 24, 2015 5:06 PM, "Neil Jerram"  wrote:

> Lovely, thanks for organizing! Looking forward to it!
>
> Neil
>
>
>   Original Message
> From: Akihiro Motoki
> Sent: Friday, 23 October 2015 17:27
> To: OpenStack Development Mailing List
> Reply To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo
>
>
> Hi Neutron folks,
>
> We are pleased to announce Neutron social meet-up in Tokyo.
> Thanks Takashi and Hirofumi for the big help.
>
> I hope many of you will be there and enjoy the time.
> If you have made RSVP, don't miss it!
> We recommend  to join the beginning, but come and join us even if you
> arrive late.
>
> 
>
> Thursday, Oct 29 19:00-22:00
> Hokkaido (北海道 品川インターシティー店)
>
> Location:
>
> https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0=sharing
> 5th floor at the "shop and restaurant building" (between A and B
> buildings).
> It is at the opposite side of JR Shinagawa Station from the Summit side.)
>
> Approximately it costs ~5000 (Japanese) Yen depending on the number of
> folks who join.
> Note that we have no sponsors.
>
> If you have any trouble in reaching there or some question, reach me
> @ritchey98 on Twitter.
>
> 
>
> See you in Tokyo!
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

2015-10-24 Thread Neil Jerram 
Lovely, thanks for organizing! Looking forward to it!

Neil


  Original Message
From: Akihiro Motoki
Sent: Friday, 23 October 2015 17:27
To: OpenStack Development Mailing List
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo


Hi Neutron folks,

We are pleased to announce Neutron social meet-up in Tokyo.
Thanks Takashi and Hirofumi for the big help.

I hope many of you will be there and enjoy the time.
If you have made RSVP, don't miss it!
We recommend  to join the beginning, but come and join us even if you
arrive late.



Thursday, Oct 29 19:00-22:00
Hokkaido (北海道 品川インターシティー店)

Location:
https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0=sharing
5th floor at the "shop and restaurant building" (between A and B buildings).
It is at the opposite side of JR Shinagawa Station from the Summit side.)

Approximately it costs ~5000 (Japanese) Yen depending on the number of
folks who join.
Note that we have no sponsors.

If you have any trouble in reaching there or some question, reach me
@ritchey98 on Twitter.



See you in Tokyo!
Akihiro

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

2015-10-24 Thread Doug Wiegley 
As an alternative, to be considered to cleaned up, note that octavia, also a 
neutron stadium project, puts its specs in its own repo, runs its own doc jobs, 
etc. Pros and cons, but just pointing out that its out there.

Thanks,
doug


> On Oct 22, 2015, at 2:47 AM, Kyle Mestery  wrote:
> 
> On Wed, Oct 21, 2015 at 12:34 PM, Armando M.  > wrote:
> 
> 
> On 21 October 2015 at 10:29, Kyle Mestery  > wrote:
> On Wed, Oct 21, 2015 at 12:08 PM, Armando M.  > wrote:
> 
> 
> On 21 October 2015 at 09:53, Kyle Mestery  > wrote:
> On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  > wrote:
> 
> 
> On 21 October 2015 at 04:12, Gal Sagie  > wrote:
> Do we also want to consider Project Kuryr part of this?
> 
> No, why would we?
>  
> The reason to consider it is because Kuryr is a sub-project of Neutron, and 
> they are doing their spec submissions following the Neutron guidelines. 
> Adding the kuryr-core gerrit group to be on part with the *aas repos makes 
> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec 
> reviews in the neutron-specs repository, then adding them makes sense too.
> 
> I don't believe this is the road we set ourselves on when we started the 
> decomp/stadium. We wanted a clear separation of concerns and I don't see how 
> going down this path is going to help us achieve that.
> 
> I don't see the grounds to have such an abrupt change in direction right now, 
> especially for the level of work that that would imply and the pressure that 
> would put on the drivers team. Anyone is free to review and contribute where 
> it matters for them, and location should not prevent them from doing so.
>  
> I was merely implying that since these projects are part of neutron, and they 
> have specs, keeping them in one place makes sense. And by doing that, we'd 
> need to give them +2 powers for their core reviewers. But, I'm fine with 
> leaving things the way they are and having them put their specs in their 
> devref. But we should update the devref in Neutron to reflect this, e.g. that 
> we don't expect specs in neutron-specs for things outside [neutron, 
> neutron-fwaas, neutron-lbaas, neutron-vpnaas].
>  
> 
> IMO, it's pretty clear from here [1], which I revised in the context of [2]. 
> Not sure if there's anything else that's left to misunderstanding.
> 
> 
> I think this [1] helps to make it 100% clearer, at least to me.
> 
> [1] https://review.openstack.org/238190 
>  
> [1] 
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
>  
> 
> [2] https://review.openstack.org/#/c/237180/ 
> 
> 
>  
>  
> We already started sending Kuryr spec to the Neutron repository and I think 
> it would make sense to manage it
> as part of Neutron spec process.
> 
> No, unless what you are asking are changes to the core. Do you have a 
> reference for me to look at?
>  
> See above, perhaps I answered this for you.
>  
> 
> Any opinions on that?
> 
> Gal.
> 
> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  > wrote:
> Hi folks,
> 
> During revision of the Neutron teams [1], we made clear that the 
> neutron-specs repo is to be targeted by specs for all the Neutron projects 
> (core + *-aas).
> 
> For this reason I made sure that the neutron-specs-core team +2 right was 
> extended to all the core teams.
> 
> Be mindful, use your +2 rights with care: if you are core on a *-aas project, 
> you should exercise that vote only for specs that pertain the project you're 
> core of.
> 
> If I could use this email as a reminder also of the core hierarchy and 
> lieutenant system we switched to in Liberty ([3]): if you have been made core 
> by a lieutenant of a sub-system, please use your +2/+A only within your area 
> of comfort and reach out for help if in doubt. 
> 
> Reviews are always welcome though!
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/237180/ 
> 
> [2] https://review.openstack.org/#/admin/groups/314,members 
> 
> [3] 
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>  
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [Heat] publicURL vs internalURL for resource validation

2015-10-24 Thread Matt Fischer 
>From an operations point of view I'd also prefer all service to service
calls to go through the internalURL is there a reason it's not default?
On Oct 24, 2015 7:56 AM, "Attila Szlovencsak" 
wrote:

> Hi!
>
> I am using Openstack Kilo (2015.1.1)
> As I learned from the code, heat-engine uses the endpoint-type "publicURL",
> when validating templates. I also see that I can override that from
> heat.conf via [clients_XXX]/endpoint_type.
>
>
> heat/engine/clients/os/nova.py
> 
> def _create(self):
> endpoint_type = self._get_client_option('nova', 'endpoint_type')
> management_url = self.url_for(service_type='compute',
>   endpoint_type=endpoint_type)
>
>
> /heat/common/config.py
> =
> # these options define baseline defaults that apply to all clients
> default_clients_opts = [
> cfg.StrOpt('endpoint_type',
>default='publicURL',
>
> 
> My questions:
>
> 1. Shouldn't we use the  interalURL instead as default?  In a typical case,
> the controller node sits behind a load-balancer, and IP for the publicURLs
> are held by the load-balancer. The controller node (so heat-engine) might
> not have access to the publicURL at all.
>
> 2. Instead of creating and "endpoint_type" entry in heat.conf for each and
> every service,  is there a simpler way to force using the internalURL?
>
> Thanks in advance,
> Attila
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

2015-10-24 Thread Doug Wiegley 
'be considered to cleaned up’

i meant OR, not to. But I note that armax’s patch already clarified this, so 
I’ll go back to my jetlag stupor. :-)

Thanks,
doug

> On Oct 24, 2015, at 9:07 PM, Doug Wiegley  
> wrote:
> 
> As an alternative, to be considered to cleaned up, note that octavia, also a 
> neutron stadium project, puts its specs in its own repo, runs its own doc 
> jobs, etc. Pros and cons, but just pointing out that its out there.
> 
> Thanks,
> doug
> 
> 
>> On Oct 22, 2015, at 2:47 AM, Kyle Mestery > > wrote:
>> 
>> On Wed, Oct 21, 2015 at 12:34 PM, Armando M. > > wrote:
>> 
>> 
>> On 21 October 2015 at 10:29, Kyle Mestery > > wrote:
>> On Wed, Oct 21, 2015 at 12:08 PM, Armando M. > > wrote:
>> 
>> 
>> On 21 October 2015 at 09:53, Kyle Mestery > > wrote:
>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M. > > wrote:
>> 
>> 
>> On 21 October 2015 at 04:12, Gal Sagie > > wrote:
>> Do we also want to consider Project Kuryr part of this?
>> 
>> No, why would we?
>>  
>> The reason to consider it is because Kuryr is a sub-project of Neutron, and 
>> they are doing their spec submissions following the Neutron guidelines. 
>> Adding the kuryr-core gerrit group to be on part with the *aas repos makes 
>> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec 
>> reviews in the neutron-specs repository, then adding them makes sense too.
>> 
>> I don't believe this is the road we set ourselves on when we started the 
>> decomp/stadium. We wanted a clear separation of concerns and I don't see how 
>> going down this path is going to help us achieve that.
>> 
>> I don't see the grounds to have such an abrupt change in direction right 
>> now, especially for the level of work that that would imply and the pressure 
>> that would put on the drivers team. Anyone is free to review and contribute 
>> where it matters for them, and location should not prevent them from doing 
>> so.
>>  
>> I was merely implying that since these projects are part of neutron, and 
>> they have specs, keeping them in one place makes sense. And by doing that, 
>> we'd need to give them +2 powers for their core reviewers. But, I'm fine 
>> with leaving things the way they are and having them put their specs in 
>> their devref. But we should update the devref in Neutron to reflect this, 
>> e.g. that we don't expect specs in neutron-specs for things outside 
>> [neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].
>>  
>> 
>> IMO, it's pretty clear from here [1], which I revised in the context of [2]. 
>> Not sure if there's anything else that's left to misunderstanding.
>> 
>> 
>> I think this [1] helps to make it 100% clearer, at least to me.
>> 
>> [1] https://review.openstack.org/238190 
>>  
>> [1] 
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
>>  
>> 
>> [2] https://review.openstack.org/#/c/237180/ 
>> 
>> 
>>  
>>  
>> We already started sending Kuryr spec to the Neutron repository and I think 
>> it would make sense to manage it
>> as part of Neutron spec process.
>> 
>> No, unless what you are asking are changes to the core. Do you have a 
>> reference for me to look at?
>>  
>> See above, perhaps I answered this for you.
>>  
>> 
>> Any opinions on that?
>> 
>> Gal.
>> 
>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. > > wrote:
>> Hi folks,
>> 
>> During revision of the Neutron teams [1], we made clear that the 
>> neutron-specs repo is to be targeted by specs for all the Neutron projects 
>> (core + *-aas).
>> 
>> For this reason I made sure that the neutron-specs-core team +2 right was 
>> extended to all the core teams.
>> 
>> Be mindful, use your +2 rights with care: if you are core on a *-aas 
>> project, you should exercise that vote only for specs that pertain the 
>> project you're core of.
>> 
>> If I could use this email as a reminder also of the core hierarchy and 
>> lieutenant system we switched to in Liberty ([3]): if you have been made 
>> core by a lieutenant of a sub-system, please use your +2/+A only within your 
>> area of comfort and reach out for help if in doubt. 
>> 
>> Reviews are always welcome though!
>> 
>> Cheers,
>> Armando
>> 
>> [1] https://review.openstack.org/#/c/237180/ 
>> 
>> [2] https://review.openstack.org/#/admin/groups/314,members 
>>

Re: [openstack-dev] [Neutron] [Tempest] where fwaas tempest tests should be?

2015-10-24 Thread Doug Wiegley 

> On Oct 19, 2015, at 5:33 PM, Ihar Hrachyshka  wrote:
> 
>> On 16 Oct 2015, at 10:50, Takashi Yamamoto  wrote:
>> 
>> if i move fwaas tests from neutron to neutron-fwaas, [1]
>> is there easy way to run them together with the rest of neutron api tests
>> for gate-neutron-dsvm-api job?
> 
> Before we jump in to reflect current gating status-quo, do we have a definite 
> answer why we want to keep the gate coupling in place? Can’t we leave the 
> fwaas api job for fwaas repo only? Do we think core is unstable enough to 
> justify additional coupling? Is core bad at handling backwards compatibility 
> when it comes to (re)moving code that is unneeded for the core repo?

Core is absolutely dreadful at backwards compatibility (I’m talking recent 
history here.) The co-gate is necessary to guard against that at the moment.

Thanks,
doug

> 
> That may actually be a dumb question, so don’t hesitate to point out obvious 
> reasons to keep co-gating.
> 
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev