Open Stack

Hi Kyle

I totally agree with you. In option 2-2, we have driver architecture
and L3 functions should be also an driver.
Option 2-1 is just for easy migration path.

Best
Nachi

2013/5/15 Kyle Mestery (kmestery) <kmestery at cisco.com>:
> On May 14, 2013, at 5:31 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>
>> Hi Sumit and Networking folks
>>
>> This is continuing discussion of this week openstack networking project.
>> Multiple service is going to inject new function for Logical Router,
>> however we are lacking framework for injecting functions for l3-agent
>>
>> so I wrote some options in this slide.
>>
>> https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZXq7SnSSGo/edit#slide=id.p
>>
>> I prefer Option2-1 for now, and migrate for option2-2 later in the slide.
>>
> How does Option2-1 work when you want to provide the service functionality with something other than an L3 agent? For Option2-2, this becomes a bit clearer to me as you have the concept of "drivers" for the functionality. For routing functionality, keep in mind that Bob Melander is migrating more to this pluggable approach with his L3 changes for this blueprint:
>
> https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin
>
> Once that happens, there could be multiple L3 agents, or even L3 functionality without an agent, depending on how a plugin implements things. Perhaps this should be taken into consideration here as well.
>
> Thanks,
> Kyle
>
>> Thanks
>> Nachi
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev