Open Stack

Hi Youcef,

sorry about the delay in my reply.
I think consensus about the right approach is starting to maturing. I
totally agree with you on the need for having clear interfaces.

For the L3 functionality, at the summit we decided to regard it as "core".
And indeed I already have a blueprint for moving the APIs from extensions
to core.
So, technically speaking, L3 will become part of the core plugin.

However, as I also discussed on the wiki page, I'd like community input to
understand how to deal with Floating IPs, which despite being part of the
L3 extension kind of represent an "advanced" service.

Salvatore

On 2 November 2012 20:00, Youcef Laribi <Youcef.Laribi at eu.citrix.com> wrote:

> Thanks Salvatore. I’m also in favor of loading several plugins and have
> clean interfaces between them.****
>
> ** **
>
> Does this mean the L3 functionality will be factored out in its own plugin
> if we go with the “multiple plugins” approach, or will you keep it in the
> “core plugin” ? ****
>
> ** **
>
> Youcef
>


> ****
>
> ** **
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* Friday, November 2, 2012 10:28 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Quantum][LBaaS] Advanced Services
> Insertion****
>
> ** **
>
> Youcef,****
>
> ** **
>
> The proposals you've described are exactly the ones being considered on
> the wiki page.****
>
> I am considering both at the moment, and I'm evaluating them along the
> following dimensions:****
>
> 1) Flexibility (and the multiple plugins approach here is a winner,
> probably)****
>
> 2) Impact on Quantum architecture (single plugin would be the one with the
> lowest impact)****
>
> 3) Implementation effort (here I am still undecided, as the approach with
> a single plugin ends up moving the complexity from Quantum server to the
> plugin)****
>
> ** **
>
> It seems we have not yet a clear decision, but several people from the
> community are advocating for clean, separate interfaces among plugins.****
>
> Another option we might consider is whether we start adopting 1 plugin per
> type of service (so 1 core plugin, 1 firewall plugin, 1 load balancing
> plugin), and update quantum to dispatch the call to the appropriate plugin.
> ****
>
> On this single 'LB' plugin we can immediately start providing an OSS
> implementation, so that Quantum users will have the ability of testing the
> feature. Vendor-specific plugin might follow suit. What we will not have
> immediately (and I mean G-1 or G-2) is the ability of serving multiple
> providers at the same time, which is one of the fundamental requirements
> for LBaaS, but we can commit to add this capability by G-3.****
>
> ** **
>
> Thanks,****
>
> Salvatore****
>
> ** **
>
> On 2 November 2012 16:45, Youcef Laribi <Youcef.Laribi at eu.citrix.com>
> wrote:****
>
> Thanks Eugene, Salvatore for validating the current situation. Now  let me
> try to understand the changes we are proposing for incorporating LBaaS and
> other “advanced services”.****
>
>  ****
>
> All current “Core plugins” in Quantum like the “Linux Bridge” plugin
> implement the L2 core APIs, and some of these plugins also implement the L3
> extension. Today, there can only be one “core plugin” running in Quantum.
> So, the total of the APIs supported will depend the core plugin that was
> configured.****
>
>  ****
>
> Are we saying, that we will modify some of these core plugins to also
> implement the LBaaS extension, so they will expose the LBaaS APIs in
> addition to the L2 and L3 APIs ?  If not, is the proposal to modify Quantum
> to support more than one plugin at a time (a “core” one + others) ? ****
>
>  ****
>
> Youcef****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* Friday, November 2, 2012 2:11 AM****
>
>
> *To:* OpenStack Development Mailing List****
>
> *Subject:* Re: [openstack-dev] [Quantum][LBaaS] Advanced Services
> Insertion****
>
>  ****
>
> Youcef,****
>
>  ****
>
> I think that picture describes quite well the framework Quantum is already
> adopting for l2/l3 connectivity.****
>
> We could do down that route for LBaaS as well. However for supporting
> multiple providers we'll need to keep in mind that we might need some
> logic, within the Quantum plugin for dispatching to the appropriate agent.
> ****
>
>  ****
>
> With your permission, I will take your picture and use it in the service
> insertion wiki page, which I will update with the outcome of the recent
> discussions we had.****
>
>  ****
>
> Salvatore****
>
> On 2 November 2012 07:22, Eugene Nikanorov <enikanorov at mirantis.com>
> wrote:****
>
> Hi Youcef,****
>
>  ****
>
> The picture you've made is quite accurate. ****
>
> My opinion is that we should adopt the same approach for lbaas, e.g.
> extension - plugin - agent - drivers.****
>
>  ****
>
> Thanks,****
>
> Eugene.****
>
> On Fri, Nov 2, 2012 at 10:44 AM, Youcef Laribi <
> Youcef.Laribi at eu.citrix.com> wrote:****
>
> Eugene, Salvatore,****
>
>  ****
>
> In order to clarify the terminology in our meetings and not get confused,
> I’m trying to draw a picture that represents how Quantum is organized today
> (mostly for myself). I have uploaded an attempt here:****
>
>
> http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Internal+components.png
> ****
>
>  ****
>
> Can you please check it for accuracy since you are familiar with the code?
> Once we agree and understand this picture, we can more easily discuss what
> needs to be changed in Quantum to accommodate LBaaS.****
>
>  ****
>
> Youcef****
>
>  ****
>
> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *Sent:* Wednesday, October 31, 2012 6:32 AM
> *To:* openstack-dev at lists.openstack.org
> *Subject:* [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion***
> *
>
>  ****
>
> Hi Salvatore,****
>
>  ****
>
> I'd like to give some feedback/questions based on yesterday's meeting
> discussion and your renewed
> http://wiki.openstack.org/Quantum/ServiceInsertion page.****
>
>  ****
>
> First of all, I think it's worth to fix the terminology just to avoid any
> confusion:****
>
>  ****
>
> - extension (API extension) - set of REST calls****
>
> - plugin - code that implements certain API, works with quantum database,
> pushes calls to agents****
>
> - core plugin - code that implements core API (networks, subnets, ports,
> L3)****
>
> - agent - listens to commands from plugin, applies configuration to
> particular device type, ex: ovs agent, L3 agent****
>
> - driver - code that applies conf to particular device type. That is just
> another layer needed to support different device types. Example:
> Loadbalancing agent may have several drivers to talk to different LB
> devices.****
>
>  ****
>
> Some thoughts on the Service Insertion proposal:****
>
>  ****
>
> 1. It seems that multiplugin approach is the right way to move further
> compared to "mixin" approach where we inject and modify code of the core
> plugin.****
>
> This will preserve plugin independency while require some changes to
> infrastructure (plugin loading, extension management).****
>
>  ****
>
> 2. Having several implementations of the same service type.****
>
> If all services of the certain type implement the same calls, then
> something should allow to route the call to particular plugin.****
>
> The options include:****
>
>   1)  passing particular service impl as a url parameter****
>
>   2)  having a prefix in uri for certain svc type:
> /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json****
>
>   3)  having (tenant, service implementation) assosiation in DB that will
> allow to route a call automatically. But this makes 1 to 1 relation, e.g.
> tenant will have only 1 impl of service available****
>
>  ****
>
> My preference is (2): first of all, it "splits" whole API between core API
> and Adv Svc API, and also does so for different service type
> implementations.****
>
> Although URIs may not be so short as we want them, that could prevent from
> naming collisions between different service types.****
>
>  ****
>
> 3. Service Insertion:****
>
> I was thinking about routed/floating-mode insertion and there is a certain
> thing I don't understand: the workflow.****
>
> It seems that the whole thing is somehow close to what we used to call
> "device management" in mirantis implementaion of lbaas, but it doesn't look
> like solving all device management tasks.****
>
>  ****
>
> So in our implementation of LBaaS the workflow was as following:****
>
> 1) admin creates the device. Essentially it's just an instruction to LBaaS
> of where is the device (it's address), which type is it and credentials to
> manage it.****
>
> 2) tenant creates VIP. During this operation LBaaS chooses the most
> appropriate device from the list of available and makes appropriate device
> configuration****
>
>  ****
>
> If we're talking about workflow within Quantum it could look like
> following (scenario 1 - shared HW device):****
>
> 1) admin creates the device. The same as in lbaas - address, type,
> credentials****
>
> 2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures
> connectivity between the device and tenant network (possibly with l3 router
> configuration), ****
>
> configures loadbalancer according to provided VIP parameters, possibly
> assigns floating IP from external network****
>
>  ****
>
> If we're talking about private balancer with Quantum, then:****
>
> 1) tenant creates the device. This could be a launch of VM with HA Proxy
> within tenant for instance.****
>
> 2) tenant creates VIP: LBaaS configures loadbalancer according to provided
> VIP parameters, possibly assigns floating IP from external network. No
> other actions required****
>
>  ****
>
> It would be great if you explain how service assignments for routers maps
> to device management scenarios and what exact workflow will be. ****
>
>  ****
>
> Thanks,****
>
> Eugene.****
>
>  ****
>
> _______________________________________________
> 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/20121105/8425928a/attachment.html>