Open Stack

Hi Summit

Thank you for your comment.

I have also talked with Mark at Quantum VPN meetings.
Mark suggested we should start Option1 because it may take time to
design Option2 and it may block progress of FWaaS and VPN.
I agree with him.

For first VPN implementation, we would like to extend L3agent class.
then, let's migrate for option 2-2 in the middle or late H2 :)

Thanks
Nachi


2013/5/16 Sumit Naiksatam <sumitnaiksatam at gmail.com>:
> Hi Nachi,
>
> Thanks for posting your proposal on this. I agree, we will eventually
> want to get to something similar to option 2-2. I also agree that we
> probably need to do this in a phased manner.
>
> To make immediate progress, could the option 2-1 be achieved by using
> a mixin/inheritence approach? Each service would have it's own mixin,
> which can in turn have the logic to load the appropriate driver. That
> would probably result in the least amount of changes to the l3 agent
> until we move towards something like option 2-2.
>
> Thanks,
> ~Sumit.
>
> On Wed, May 15, 2013 at 10:56 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>> 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
>>
>> _______________________________________________
>> 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