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 <gkot...@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." <arma...@gmail.com <mailto:arma...@gmail.com>> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org>> > Date: Sunday, October 4, 2015 at 8:18 PM > To: OpenStack List <openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org>> > Subject: Re: [openstack-dev] [Neutron] AZ Support > > > > On 4 October 2015 at 10:00, Gary Kotton <gkot...@vmware.com > <mailto:gkot...@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." <arma...@gmail.com <mailto:arma...@gmail.com>> >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org >> <mailto:openstack-dev@lists.openstack.org>> >> Date: Sunday, October 4, 2015 at 7:34 PM >> To: OpenStack List <openstack-dev@lists.openstack.org >> <mailto:openstack-dev@lists.openstack.org>> >> Subject: Re: [openstack-dev] [Neutron] AZ Support >> >> >> >> On 4 October 2015 at 09:19, Gary Kotton <gkot...@vmware.com >> <mailto:gkot...@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-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-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
