Open Stack

Hi Youcef,

Driver doesn't "choose" device-specific info, driver is device-specific
itself.
When we send request to the agent, we need to specify which device to use.

So once the user have chosen device type via service_type on VIP creation,
Quantum not only should associate VIP with device type, but also it should
choose particular instance of that device type to deploy the VIP.
The process of choosing the instance is called scheduling. Unlike nova it's
unreasonable for LBaaS to have separate scheduler service, thus it makes
sense to have them built in the plugin.
I think we should not do this on agent since it doesn't have (and should
not have) device database.
Not should it access quantum's database directly.

So overall workflow will look like the following:
1. Add a device (type, physical info) to device registry (this is a part of
Provider API. Call to Quantum made by cloud provider in case of shared
devices, or by tenant in case of private VM balancers)
2. Create a VIP, specifying service type (=device type) (call by tenant),
3. Choose device of specified type, associate the VIP with the device (made
by Quantum/Plugin)
4. Send message with (logical VIP info, device_type, physical device info)
to LBaaS Agent (made by Quantum/Plugin)
5. Communicate with particular device using driver according to device_type
(LBaaS Agent)

Any CRUD request processed by Agent should be supplied by device type and
device parameters.

You may think of alternative approach where device registry is held by the
Agent or even driver, but this approach has the next disadvantages:
- Scheduling goes to Agent or Driver and thus Agent/Driver should store
VIP-device association while VIP is a "foreign" object for the Agent/Driver.
- If we go with multiple agents for large deployments, we'll need to sync
their device databases
- Device locking will be complicated.
- If Agents will have non-intersecting sets of devices in their registries
than scheduling will be complicated or not possible.

Please share you thoughts on this.

Thanks,
Eugene.


On Tue, Nov 27, 2012 at 3:38 AM, Youcef Laribi
<Youcef.Laribi at eu.citrix.com>wrote:

> Hi Eugene, Leon,****
>
> ** **
>
> Could we have the LBaaS plugin choose the “driver” based on service_type
> info, and then it’s the driver which choose the “device”? The driver can
> obviously have its own DB model where it stores device-specific info.****
>
> ** **
>
> Youcef****
>
> ** **
>
> *From:* Dan Wendlandt [mailto:dan at nicira.com]
> *Sent:* Monday, November 26, 2012 9:13 AM
> *To:* Leon Cui
> *Cc:* OpenStack Development Mailing List; Salvatore Orlando
> *Subject:* Re: [openstack-dev] 答复: 答复: 答复: 答复: 答复: Progress on
> lbaas-plugin-api-crud****
>
> ** **
>
> ** **
>
> On Mon, Nov 26, 2012 at 9:03 AM, Leon Cui <lcui at vmware.com> wrote:****
>
> Hi Eugene,****
>
> When did you change get merged into master? I did rebase on last Friday
> which supposed to be your latest code, but anyway I’m planning to do it
> again today. ****
>
>  ****
>
> Thanks for your reminder that I need to include device mgmt. into DB
> model.  Need to look at Salvatore’s change on ServiceType.****
>
> ** **
>
> It seems to me that each LB plugin should be able to define its own DB
> models for "device mgmt" (e.g., device address/credentials/etc.), as
> different plugins may have different strategies for how they manage
> devices.  The usual model is that plugins can define additional
> models/tables to manage entities that are specific to that plugin.  This is
> similar to how we didn't back the notion of a "vlan" into the DB model for
> "core plugins", since not all plugins will use vlans.  If you don't go down
> this route, you end up with a messy DB model as everyone keeps adding
> columns for items that only a particular plugin needs to track.  ****
>
> ** **
>
> Dan****
>
> ** **
>
>  ****
>
>  ****
>
> Thanks****
>
> Leon****
>
> *发件人**:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *发送时间:* 2012年11月26日 4:29****
>
>
> *收件人:* Leon Cui
> *抄送:* Ilya Shakhat; Sachin Thakkar; Oleg Bondarev; Salvatore Orlando; Dan
> Wendlandt****
>
> *主题:* Re: 答复: 答复: 答复: 答复: Progress on lbaas-plugin-api-crud****
>
>  ****
>
> Hi Leon,****
>
>  ****
>
> Thanks for sending me the patch.****
>
> I've looked at it briefly, there is one major thing I was able to identify:
> ****
>
> In order to couple things together (plugin, agent, drivers), we need to
> add device management at least to DB model.****
>
> In particular, each vip should have a reference to the device (which has a
> type and address/credentials). ****
>
> This information is passed in each agent notification message.****
>
> This part is missing in current design blueprints but i think we need to
> add it before we put the code on review.****
>
> Probably it will also depend on Salvatore's ServiceTypes part.****
>
>  ****
>
> Also I see that your patch is based on some of my outdated patches. ****
>
> My code was recently merged into the master so you can rebase on master
> using only Oleg's patch.****
>
>  ****
>
> Thanks,****
>
> Eugene.****
>
> On Fri, Nov 23, 2012 at 2:40 PM, Leon Cui <lcui at vmware.com> wrote:****
>
> Hi Eugene,****
>
> I’m still waiting for approval as openstack contributor.  For now I simply
> attached the patch file that you might want to take a look first.  Once I
> got the approval, I’ll try to post the view asap.****
>
>  ****
>
> Thanks****
>
> Leon****
>
> *发件人**:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *发送时间:* 2012年11月20日 22:57
> *收件人:* Leon Cui
> *抄送:* Ilya Shakhat; Sachin Thakkar; Oleg Bondarev; Salvatore Orlando; Dan
> Wendlandt
> *主题:* Re: 答复: 答复: 答复: Progress on lbaas-plugin-api-crud****
>
>  ****
>
> Leon,****
>
>  ****
>
> I'll take agent and rpc parts.****
>
> I have registered
> https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc to
> track this.****
>
>  ****
>
> Thanks,****
>
> Eugene.****
>
> On Tue, Nov 20, 2012 at 2:16 PM, Leon Cui <lcui at vmware.com> wrote:****
>
> Hi Eugene,****
>
> Thanks for your suggestion.  It looks good to me.  I’ll work out the UT
> first, and then align the class model to the diagram as you suggested.****
>
>  ****
>
> Thanks****
>
> Leon****
>
> *发件人**:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *发送时间:* 2012年11月20日 17:32****
>
>
> *收件人:* Leon Cui
> *抄送:* Ilya Shakhat; Sachin Thakkar; Oleg Bondarev; Salvatore Orlando****
>
> *主题:* Re: 答复: 答复: Progress on lbaas-plugin-api-crud****
>
>  ****
>
> replying to all...****
>
>  ****
>
> Leon,****
>
>  ****
>
> I think tests/unit/test_db_plugin.py  is right code to refer when writing
> unit tests for db code. The only thing is that unit tests written
> in test_db_plugin.py are a bit generic, e.g. the backend plugin is
> specified in particular plugin's UTs which inherit
> from QuantumDbPluginV2TestCase. I think UTs for balancer plugin may be more
> specific, testing LoadbalancerPluginDb class.****
>
>  ****
>
> Since you need dababase utility methods from QuantumDbPluginV2 then
> it's LoadbalancerPluginDb which should inherit from such QuantumDBBase (or
> whatever you call it), so overall diagram will look like:****
>
>  ****
>
> ServicePluginBase****
>
>     |****
>
> LoadBalancerPluginBase ****
>
>     |****
>
>     |                                       QuantumDBBase ****
>
>     |                                            |****
>
> LoadBalancerPlugin  <---------- LoadBalancerPluginDb****
>
>  ****
>
> Thanks,****
>
> Eugene.****
>
>  ****
>
> On Tue, Nov 20, 2012 at 1:04 PM, Leon Cui <lcui at vmware.com> wrote:****
>
> Hi Eugene,****
>
> Thanks for your suggestion.  Please see my comments inline.****
>
>  ****
>
> One more question: I’m writing the unit test, mainly to verify the
> database functionalities for LB CRUD.  Do you think
> tests/unit/test_db_plugin.py is the right test code that I should refer
> to?  Any good suggestions on this front?****
>
>  ****
>
> Thanks****
>
> Leon****
>
> *发件人**:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *发送时间:* 2012年11月20日 16:44
> *收件人:* Leon Cui
> *抄送:* Ilya Shakhat; Sachin Thakkar; Oleg Bondarev; Salvatore Orlando
> *主题:* Re: 答复: Progress on lbaas-plugin-api-crud****
>
>  ****
>
> Hi Leon,****
>
>  ****
>
> A few thoughts on your diagram.****
>
>  ****
>
> Please consider the following:****
>
> 1) If you want something from QuantumDbPluginV2 and you feel it may be
> common plugin functionality - you need to extract it to a separate class,
> something like QuantumPluginBase, and inherit QuantumDBPluginV2 from this
> class, ServicePluginBase should inherit from that class as well.****
>
> [Leon] I need some dababase utility methods from QuantumDbPluginV2.
> Abstract to a separate class could be a good idea. But I’m not sure if it’s
> a good idea to let ServicePluginBase to inherit from this class.
> ServicePluginBase is an abstract class for service plugin service (quantum
> manager) to use. ****
>
>  ****
>
> 2) LoadBalancerPluginBase imho should inherit from ServicePluginBase****
>
> [Leon] Why it needs to inherit from ServicePluginBase?
> LoadBalancerPluginBase defines the loadbalancer extension APIs.  I think we
> just make sure LoadbalancerPlugin inherits from both classes as below:****
>
> ServicePluginBase    QuantumPluginDbBase   LoadbalancerPluginBase****
>
>        |                       |                      |****
>
>         ----------------------------------------------****
>
>                                |****
>
>                         LoadbalancerPlugin    ------ LoadbalancerPluginDb*
> ***
>
>               ****
>
> LoadbalancerPlugin will contain the LoadbalancerPluginDb instance for
> database access.****
>
>  ****
>
>  ****
>
> 3) Depending on what you need from QuantumDbPluginV2/QuantumPluginBase,
> this may lead to the following inheritance sequence:****
>
> QuantumPluginBase****
>
>     |****
>
> ServicePluginBase****
>
>     |****
>
> LoadBalancerPluginBase ****
>
>     |****
>
> LoadBalancerPluginDb****
>
>     |****
>
> LoadBalancerPlugin****
>
>  ****
>
> Also, I think that LoadBalancerPlugin should not
> inherit LoadBalancerPluginDb. ****
>
> Unlike core plugins where it could make sense, I'd prefer to
> see LoadBalancerPluginDb to be a part of LoadBalancerPlugin.****
>
> I mean LoadBalancerPlugin implements "has a" LoadBalancerPluginDb  instead
> of "is a" relation. ****
>
> The reason for this is that LoadBalancerPlugin provides CRUD
> implementation which doesn't directly map to DB operations implemented
> in LoadBalancerPluginDb. ****
>
> E.g. my idea is:****
>
> LoadBalancerPlugin - CRUD, validation, calling LoadBalancerPluginDb,
> sending/receiving messages to agent****
>
> LoadBalancerPluginDb - DB access.****
>
>  ****
>
> Thanks,****
>
> Eugene.****
>
>  ****
>
> On Tue, Nov 20, 2012 at 6:54 AM, Leon Cui <lcui at vmware.com> wrote:****
>
> Hi Ilya,****
>
> Right now I took Eugene’s change under review (
> https://review.openstack.org/#/c/15733/) and am developing the database
> access logic and plugin skeleton based on that service plugin mechanism. The
> class model is illustrated in the below diagram:****
>
> [image: ServicePluginBase (quantum.plugins.services.service_base)
> ,QuantumDbPluginV2 (quantum.db. db_base_plugin_v2),LoadBalancerPluginDb
> (quantum.plugins.services.loadbalancer.loadbalancer_db),LoadBalancerPluginBase
> (quantum.extensions.loadbalancer)]****
>
> [image: LoadBalancerPlugin
> (quantum.plugins.services.loadbalancer.loadbalancerPlugin)]****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>
> ****
>
> LoadBalancerPlugin module is the main body of loadbalancer plugin which
> inherits from multiple classes:****
>
> -          ServicePluginBase: defines the abstract methods that a service
> plugin should implemented.****
>
> -          QuantumDbPluginV2: contains a set of generic quantum database
> access methods. I’m not sure if we really want to inherit from this class
> but I’d like to leverage the methods defined in this class.****
>
> -          LoadBalancerPluginDb: This the main part I’m coding on which
> wrap the Lbaas database model and CRUD operation against the database.****
>
>  ****
>
> My thought is that LoadBalancerPlugin will control the LBaaS CRUD API
> flow. For instance, “create_vip” method should first validate the input,
> update the database, send message to the LbAgent over AMQP channel, than
> update the database by setting the status from PENDING_CREATE to ACTIVE.**
> **
>
>  ****
>
> I’m trying to write unit tests against the database access now which will
> take a while to complete. Meanwhile it would be great to have your help on
> coding the RPC interaction between plugin and agent.****
>
>  ****
>
> I don’t like blocking your part. What’s the best practice to collaborate
> with you on this? Maybe I can shelve my change to you somehow?****
>
>  ****
>
> Thanks****
>
> Leon****
>
> *发件人**:* Ilya Shakhat [mailto:ishakhat at mirantis.com]
> *发送时间:* 2012年11月19日 22:08
> *收件人:* Sachin Thakkar; Leon Cui
> *抄送:* Eugene Nikanorov; Oleg Bondarev
> *主题:* Progress on lbaas-plugin-api-crud****
>
>  ****
>
> Hi Sachin, Leo, ****
>
>  ****
>
> Recently there was a thread related to LBaaS architecture (
> http://lists.openstack.org/pipermail/openstack-dev/2012-November/002646.html).
> How good is it aligned with your implementation? Do you need help in
> coding? (we may take Agent part) ****
>
>  ****
>
> Thanks,****
>
> Ilya****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>
>
> ****
>
> ** **
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: www.nicira.com****
>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ** **
>
> _______________________________________________
> 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/20121127/18d54225/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13351 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/18d54225/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1745 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/18d54225/attachment-0001.png>