Open Stack

Hi folks,

I'd like to go back in this thread to the terminology discussion.
There we mentioned agents and drivers and you said* "**a plugin which
directly dispatches commands to drivers, rather than relying on agents".*
 Also, I think in some of discussions "plugin" was considered to implement
API for one kind of device only, therefore that "multiple coexisting
plugins" problem.
Such considerations greatly affect the whole architecture of plugin as well
as some important implementation details.

Let me explain why it is important:

1. That defines relationship between plugin and device types.
Option (a):
   we have several plugins implementing same LBaaS API where each plugin
talks to it's device type via driver.
   That approach creates more complicated routing problem where you need to
know the type of device to route the call to the proper plugin.
Option (b):
   we have one plugin and several drivers. LBaaS picks a driver depending
on a type of device to which logical object is bound (VIP, Pool, etc)
   That approach avoids any additional call dispatching, e.g. nothing else
should be done except for specifying a controller for a REST call, which is
LBaaS plugin itself.

2. Whether to have an agent.
Option (a):
   LBaaS plugin(s) talk directly to drivers, e.g. make synchronous calls.
   That may create additional complexity on plugin side because we need to
reply asynchronously to REST calls while device operations remain
synchronous. That will require additional mechanisms such as queuing
synchronous calls, separate thread to handle calls from the queue, etc

Option (b):
   LBaaS plugin talk with LBaaS agent via mq. Agent uses appropriate driver
to perform device operations, upon completion it sends message back to
queue. That's not only goes inline with what other plugins do but also
moves complexity from plugin to agent, which is dedicated for such king of
tasks.

My choices (1.b, 2.b) is based on current Mirantis LBaaS implementation
which can be easily mapped on three typical entities of Quantum:
- extension for LBaaS REST API
- plugin (LBaaS core) - for DB functionality, device scheduling,
interaction with agent
- agent - awaits commands from the plugin and applies them to devices using
drivers.

Some answers to Sasha's questions:
*> I am also looking forward to the answer regarding the semantics of
associating "service" to (logical) "router".*
We discussed this with Salvatore. It appears that this is needed for the
tenant to provide LBaaS information about which kind of service (in our
case, which kind of LB) it is looking for.
E.g. tenant would specify router_id in LB-related calls and this will allow
LBaaS extract LB type from (router, service type) association and schedule
proper device. It also means that for each kind of LB we need to have
logical router with corresponding association.
The only question left - why do we need to use the notion of router at all?
Could tenant directly specify device type (or service type) when requesting
a service?

*> was the intention that agent would expose "device_type" APIs (service
resource abstraction) and drivers would map that to "device_type_vendor"
API?*
I can say for current LBaaS implementation: device drivers implement the
same public API which is "least common denominator" of several
device-specific APIs. Additional features may be implemented as different
"extra" fields in REST calls/DB and functions around them.
So the bottom line is that API (extension, plugin, agent) is the same for
any kind of devices but yet some extensibility is possible with those
"extra"'s
I think it is reasonable approach and we should apply it for LBaaS plugin.

*> If "multi plugin" approach is chosen,  with each plugin having its own
db (per definition above), it becomes extremely important to have some way
for plugins to have coherently manage resources that may have their
representations reside in both dbs. * *( Say "port" in core API is sort of
extended in LBaaS as "pool member" - I.e. Adding/deleting the port impacts
obviously pool member). Is this a valid concern? *
That's a good question. Deleting port could effectively disable a pool
member while LBaaS will not know about it.
We can think of some kind of NotifierAPI for such cases: plugins will
subscribe to core resource changes and make corresponding changes in their
DBs as well as changes in affected device configurations.

*> Is is viable to have these different service implementations "advertise"
properties  of that implementation, via an attribute (TBD) of the service
object (VIF in case of LBaaS) so that tenant uses that information to chose
implementation? In other words, choosing that property of the "service"
object indicates the hint as to which implementation to use.*
In current LBaaS implementation such hint could be: balancing algorithm,
requested throughput, etc.
These properties indirectly specify particular device type and some of them
could point to specific device of the same type (less loaded, cheapest,
etc).


Looking forward to your feedback as I see there are still some uncovered
points of "service insertion" both on logical side and on code architecture
side.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121102/b27c0199/attachment.html>