Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130517/3d03ba2d/attachment.html>