Open Stack

Hi folks,

One of the major features that we need to implement during Havana (H-1 at
best) is true flexible multivendor support.
There could be different ways of giving tenant ability to choose vendor of
requested loadbalancer, but we need to evaluate how service types could
help us on this way.

The reason I'm writing this is that I'd like to make some terminology
cleanup and set up key design points to discuss and move forward.

Let's start with what we have on service types today:
1) Description of the feature:
https://wiki.openstack.org/wiki/Quantum/ServiceInsertion
2) Code:
https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py
3) seems to be framework is not used (and doesn't have respective CLI code)
so changing it would not be painfull if we want to.

*I'd like to set service insertion problem aside and focus on service types
as a way to choose vendor.*

So, on terminology side we have the following enitities (from code and
docs):
- Service Type - defines a set of service providers (plugins:drivers)
- Service Definition - defines one service provider
- Service Class - a type of service (?!) (LB, FW, VPN)

1) So, first of all terminology seems to be quite confusing, especially
word "type" is overloaded.
I think we need to propose better names for the these entities just to
simplify our thinking about the integration with services.

So, my proposal would be:
- Service Type - LB, FW, VPN
- Service Type Provider - defines one service provider (former Service
Definition) (alt: Service Type Definition)
- Service Group - what used to be Service Type. (alt: Service Set, ??)

Until agreed, I'll use old terminology.

2) The relationship between Service Types and Service Definitions.
It is not obvious (nowhere stated or enforced) but Service Type must have
just one Service Definition of the same Service Class,
otherwise, Service Type is useless for API call dipatching. E.g. there
should be 1:1 mapping between Service Type and Service Definition for
certain Service Class.

3) API calls dispatching. The most important question: whether or not to
support multiple plugins per Service Class.
In other words, whether to have several Service plugins (several lbaas
plugins, for ex) loaded simultaneosly.
My opinion is that we don't need that as multi-vendor support could be
implemented more simple plugin-side drivers.
To make this shorter, I'll skip explanation for now.

So in order to move forward I'd suggest we have a meeting with the
following agenda:
1. Terminology
2. Service type framework refactoring.
3. API calls dispatching: hints and control flow.
I'll prepare some suggestions/diagrams about this.

We could have a meeting someday this week at 8:00 - 10:00 AM PST, late
evening PST will also work for me.

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