Open Stack

Hi,

2015-10-05 15:54 GMT+09:00 Gary Kotton <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:
>       1. 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.


>    1.
>       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)
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>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Sunday, October 4, 2015 at 8:18 PM
>
> To: OpenStack List <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> 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>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: Sunday, October 4, 2015 at 7:34 PM
>> To: OpenStack List <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> 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://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
>>
>>
>
> __________________________________________________________________________
> 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/2b93bfcb/attachment.html>