[openstack-dev] [Neutron] AZ Support

Gary Kotton gkotton at vmware.com
Mon Oct 5 13:30:32 UTC 2015



From: Akihiro MOTOKI <amotoki at gmail.com<mailto:amotoki at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, October 5, 2015 at 3:48 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] AZ Support

Hi,

2015-10-05 15:54 GMT+09:00 Gary Kotton <gkotton at vmware.com<mailto:gkotton at vmware.com>>:
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:

  1.  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)

The proposed "AZ support" feature in Neutron is the really initial step and we have many points which can be improved.
The first step of AZ support is only related to the agent scheduling andit just tries to assign agent(s) from AZ(s) which users want.
Networks are still shared across AZs, so I don't think there are upgrade impacts on Nova.

[Gary] Thanks for that clarification. From https://review.openstack.org/#/c/204436/ is did not really seem like that is the case, but I need to go over that in more detail. When will Nova know when to pass the AZ to Neutron? Will this be if the extension is supported? I am just failing to understand  the nova side of the integrations.


  1.
     *   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 think Floating IP pool per AZ is a straight forward approach.
However, this does not necessarily mean an external network should limit to a specific AZ.
Of course, it is better that VMs in AZ1 connect to a network (whose dhcp-agent lives in AZ1)

[Gary] So each time a new AZ is created the admin will need to update the Neutron configuration file - https://review.openstack.org/#/c/183369/40/etc/neutron.conf,cm?

and the network is connected to router in AZ1.
The question is how users can select floating IP pool but in this case users can know which FIP pool belongs to which AZ.

There are other approaches. One possible option is to have one external network and
a router supports multiple upstream links using routing protocols.

I just wrote approaches in my mind and there must be more options.


  1.  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 agree that Cells support is one of missing areas in Neutron.
I think AZ support and Cells support are different things though they are similar.
AZ support is visible to users and Cells are not.

Thanks,
Akihiro


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/

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). 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



__________________________________________________________________________
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



__________________________________________________________________________
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


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


More information about the OpenStack-dev mailing list