From: Akihiro MOTOKI <[email protected]<mailto:[email protected]>> Reply-To: OpenStack List <[email protected]<mailto:[email protected]>> Date: Monday, October 5, 2015 at 3:48 PM To: OpenStack List <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [Neutron] AZ Support
Hi, 2015-10-05 15:54 GMT+09:00 Gary Kotton <[email protected]<mailto:[email protected]>>: 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." <[email protected]<mailto:[email protected]>> Reply-To: OpenStack List <[email protected]<mailto:[email protected]>> Date: Sunday, October 4, 2015 at 8:18 PM To: OpenStack List <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [Neutron] AZ Support On 4 October 2015 at 10:00, Gary Kotton <[email protected]<mailto:[email protected]>> 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." <[email protected]<mailto:[email protected]>> Reply-To: OpenStack List <[email protected]<mailto:[email protected]>> Date: Sunday, October 4, 2015 at 7:34 PM To: OpenStack List <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [Neutron] AZ Support On 4 October 2015 at 09:19, Gary Kotton <[email protected]<mailto:[email protected]>> 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: [email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
