Open Stack

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