Open Stack

I agree. With your patch it ought to be possible to make the distributed router a provider type so to me it seems like a good match.

Thanks,
Bob

From: Gary Duan <gduan at varmour.com<mailto:gduan at varmour.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: måndag 23 december 2013 19:17
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] Neutron Distributed Virtual Router

Regarding using 'provider' in L3 router, for the BP 'L3 service integration with service framework', I've submitted some code for review, which is using 'provider' in a same notion as other advanced services. I am not sure if it can be reused to describe 'centralized' and 'distributed' behavior.

https://review.openstack.org/#/c/59242/

Thanks,
Gary


On Wed, Dec 11, 2013 at 2:17 AM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:
I generally tend to agree that once the distributed router is available, nobody would probably want to use a centralized one.
Nevertheless, I think it is correct that, at least for the moment, some advanced services would only work with a centralized router.
There might also be unforeseen scalability/security issues which might arise from the implementation, so it is worth giving users a chance to choose what router's they'd like.

In the case of the NSX plugin, this was provided as an extended API attribute in the Havana release with the aim of making it the default solution for routing in the future.
One thing that is worth adding is that at the time it was explored the ability of leveraging service providers for having a "centralized router provider" and a "distributed" one; we had working code, but then we reverted to the extended attribute. Perhaps it would be worth exploring whether this is a feasible solution, and whether it might be even possible to define "flavors" which characterise how routers and advanced services are provided.

Salvatore


On 10 December 2013 18:09, Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>> wrote:
I'm +1 for 'provider'.

2013/12/9 Akihiro Motoki <motoki at da.jp.nec.com<mailto:motoki at da.jp.nec.com>>:
> Neutron defines "provider" attribute and it is/will be used in advanced services (LB, FW, VPN).
> Doesn't it fit for a distributed router case? If we can cover all services with one concept, it would be nice.
>
> According to this thread, we assumes at least two types "edge" and "distributed".
> Though "edge" and "distributed" is a type of implementations, I think they are some kind of "provider".
>
> I just would like to add an option. I am open to "provider" vs "distirbute" attributes.
>
> Thanks,
> Akihiro
>
> (2013/12/10 7:01), Vasudevan, Swaminathan (PNB Roseville) wrote:
>> Hi Folks,
>>
>> We are in the process of defining the API for the Neutron Distributed Virtual Router, and we have a question.
>>
>> Just wanted to get the feedback from the community before we implement and post for review.
>>
>> We are planning to use the “distributed” flag for the routers that are supposed to be routing traffic locally (both East West and North South).
>> This “distributed” flag is already there in the “neutronclient” API, but currently only utilized by the “Nicira Plugin”.
>> We would like to go ahead and use the same “distributed” flag and add an extension to the router table to accommodate the “distributed flag”.
>>
>> Please let us know your feedback.
>>
>> Thanks.
>>
>> Swaminathan Vasudevan
>> Systems Software Engineer (TC)
>> HP Networking
>> Hewlett-Packard
>> 8000 Foothills Blvd
>> M/S 5541
>> Roseville, CA - 95747
>> tel: 916.785.0937<tel:916.785.0937>
>> fax: 916.785.1815<tel:916.785.1815>
>> email: swaminathan.vasudevan at hp.com<mailto:swaminathan.vasudevan at hp.com> <mailto:swaminathan.vasudevan at hp.com<mailto:swaminathan.vasudevan at hp.com>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
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/20131223/3553777b/attachment.html>