Open Stack

Hi llya

That's sounds great.
So please also check FWaaS patch and VPN patch which will be posted.

Basically, I agree  with the concept of
https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-scheduler.

This is my comment for the BP.

- Now, it is not lbaas specific. so the name should be service-agent-scheduler
- It should be merged with current quantum scheduler framework.

Now, l3 is scheduled by quantum scheduler. But L3 is going to be a service.
We can also let DHCP as a service. if so it is very natural  to have
one scheduling mechanism in quantum.

Best
Nachi


2013/5/17 Ilya Shakhat <ishakhat at mirantis.com>:
> Hi Nachi, Sumit,
>
> I've discussed service agent proposal with Eugene and Oleg - option 2-2 look
> the most preferable from architecture point-of-view. We'd like to help with
> its implementation, so to make it possible for VPNaaS and FWaaS to migrate
> to it in late H2.
>
> Let's use
> https://blueprints.launchpad.net/quantum/+spec/quantum-service-agent to
> track all work on service agents. We also plan to adapt LBaaS agent to agent
> scheduler framework, the corresponding bp is
> https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-scheduler
>
> Thanks,
> Ilya
>
> 2013/5/17 Nachi Ueno <nachi at ntti3.com>
>>
>> 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
>>
>> _______________________________________________
>> 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
>