Open Stack

Hi Gary,

Thank you for your suggestion.
In Liberty cycle[1], I have discussed about these points with neutron folks and network operators.


> On 2015/10/05, at 15:54, Gary Kotton <gkotton at vmware.com> wrote:
> 
> Hi,
> Yes, you are correct. That patch is the culprit (my bad and once again humble apologies)
> 
> Regarding the AZ support I think that we need to do the following:
> Have this in a separate topic until it is complete. I have a number of concerns here:
> The upgrade impact on Nova. Today in Nova one can have N AZ’s and they will all work on the same virtual networks. It is not clear how this will work here and if the networks can be shared across AZ’s (maybe this was discussed and I am missing somehing)
> A few weeks ago Monty raised concerns about floating IP support. I think that this will be required for AZ support. In the past one could have a shared network between AZ’s and now they will need two isolated networks
I guess that this is similar to “Segment” discussion[2].
I tried to include this point to Availability Zone spec so that we can deploy an environment has network unreachable AZs.
However, some folks disagreed with this because availability zone must be something to give users High Availability not manage isolated network with AZ.

> 
> In Nova on of the top priority features over the last few cycles has been cells. At the moment there is no cell support for Neutron. I feel that the AZ support is someone what related and maybe we should try and kill 2 birds with one stone here and have the cell support combined if possible. I think that this is certainly something that should be a cross project summit discussion.
I think too that Neutron Cell Support is important. However, neutron quite depends on the backend unlike nova.
It’s hard to combine it and it will take a long time. AZ support is also different from Cell support.
We should not discuss these to connect Neutron AZ support with Cell support because I’m afraid to fall between two stools.
I agree that we have a cross project summit discussion to connect Nova Cell support with Neutron Cell support.

[1]: https://review.openstack.org/#/c/169612/ <https://review.openstack.org/#/c/169612/>
[2]: https://bugs.launchpad.net/neutron/+bug/1458890 <https://bugs.launchpad.net/neutron/+bug/1458890>

Thanks,
Hirofumi


> Thanks
> Gary
> 
> From: "Armando M." <armamig at gmail.com <mailto:armamig at gmail.com>>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> Date: Sunday, October 4, 2015 at 8:18 PM
> To: OpenStack List <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [Neutron] AZ Support
> 
> 
> 
> On 4 October 2015 at 10:00, Gary Kotton <gkotton at vmware.com <mailto:gkotton at vmware.com>> wrote:
>> The DHCP agent has the following exception:
>> 
>> 2015-10-02 23:57:05.787 ERROR neutron.agent.dhcp.agent [req-17c3aa12-41fd-41f8-8e23-2f9740e50746 None None] Failed reporting state!
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent Traceback (most recent call last):
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 572, in _report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     self.state_rpc.report_state(ctx, self.agent_state, self.use_call)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/opt/stack/neutron/neutron/agent/rpc.py", line 86, in report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     return method(context, 'report_state', **kwargs)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 158, in call
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     retry=self.retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 90, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     timeout=timeout, retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 431, in send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 420, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     result = self._waiter.wait(msg_id, timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 318, in wait
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     message = self.waiters.get(msg_id, timeout=timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 223, in get
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent     'to message ID %s' % msg_id)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent MessagingTimeout: Timed out waiting for a reply to message ID f4ed0bd26feb462c9b7b49a6d85caeae
>> 
>> Now when I use the stable/liberty branch everything is OK
>> 
> 
> Ah, I suspect that's your culprit:
> 
> https://review.openstack.org/#/c/226362/ <https://review.openstack.org/#/c/226362/>
> 
> instead of AZ's initial support.
>  
>> Thanks
>> Gary
>> 
>> From: "Armando M." <armamig at gmail.com <mailto:armamig at gmail.com>>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
>> Date: Sunday, October 4, 2015 at 7:34 PM
>> To: OpenStack List <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
>> Subject: Re: [openstack-dev] [Neutron] AZ Support
>> 
>> 
>> 
>> On 4 October 2015 at 09:19, Gary Kotton <gkotton at vmware.com <mailto:gkotton at vmware.com>> wrote:
>>> Hi,
>>> It appears that the addition has broken the vmware_nsx plugin (https://review.openstack.org/183369 <https://review.openstack.org/183369>). We are still debugging. Would it be worthwhile considering adding this support as a feature branch and then when the entire feature is ready that we merge it to the tree. This will enable the external vendors to be alive and kicking.
>> 
>> Please let us know how we can help you to fix it. The CI hasn't voted on this patch since May 14, so clearly the breakage flew under the radar.
>>  
>>> Thanks
>>> Gary
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>> 
>> 
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151005/587ee714/attachment.html>