Open Stack

Some comments inline.
Thanks for starting this discussion.
Hopefully this time we'll manage to convert thought into code in a
reasonable time.

Salvatore


On 30 April 2013 17:31, Sumit Naiksatam <sumitnaiksatam at gmail.com> wrote:

> Hi Eugene,
>
> Thanks for bringing this up. We tried to discuss some of these in the
> "services chaining, insertion, and steering" session during the summit.
> Based on the discussion and feedback (and also from implementing a
> prototype involving multiple service "types") my responses inline.
>
> ~Sumit.
>
> On Tue, Apr 30, 2013 at 8:34 AM, Eugene Nikanorov <enikanorov at mirantis.com
> > wrote:
>
>> 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.
>>
>
Agreed; the framework was conceived since it looked like 1000 different
drivers and plugins were going to be pushed for Grizzly.
That did not go that way, and using a service type where you have only a
single type of service does not make a lot of sense.


>
>> *I'd like to set service insertion problem aside and focus on service
>> types as a way to choose vendor.*
>>
>
I totally agree on this point; still this is too a kind of 'service
insertion' or 'selection' if you want not to create confusion.
>From past experience, confusion on terminology is the 1st reason for
disagreement which slows down progress due to infinite cycles of discussion.


>
>> 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)
>>
>
Pretty much that's it. It very simple: a servite type is a list of service
definition. Each service definition has a service class (whose semantics
are exactly the one you listed), a plugin, and a driver.


>
>
>> 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, ??)
>>
>
I agree with the overlap on type. This is why I used 'Class' I am happy
with renaming class to type. Service Group is probably still ambiguos, and
I will go with Service Offering.
Yes, I am copying Cloudstack here if you're wondering.



>
>>
> Sumit: How about a top level "service_type" class (consistent with current
> definition) with attributes like:
> - Category, e.g. LB, FW, VPN
> - Vendor, e.g. XYZ
> - Insertion Model, e.g. L3, L2, Bump-in-the-wire, Tap (I know you
> mentioned that you want to keep this aside for now, but I am stating it
> here for completeness)
> - Provider, name of the class which implements this service (one per type
> as you suggest later)
>

Not sure the vendor is needed; and we can rediscuss the insertion mode once
the terminology is clarified. Your proposal make sense, but I am with
Eugene here on focusing on multi-vendor selection first.


>
> 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.
>>
>
We were wishing to have multiple 'plugins' for the same 'service class'.
This is not going to happen not even for havana. I would keep the db model
flexibile and enforce the constraint in the API.


>
>>
> Sumit: We also need a base service class definition that can be used
> across services. This should support a contract for creating multiple
> logical instances of the service (e.g. one more logical Firewalls
> devices/instances as requested by a tenant). It should also support the
> attributes required to help service insertion (since the service
> implementor knows how the service will attach to the network).
>
>
>> 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.
>>
>
I agree with you; this is a need we might have in the future, and
non-negligible infrastructure changes are needed.



>
>>
> Sumit: A complementary part of this discussion is the ability for one
> plugin to support multiple services. We discussed this briefly during the
> summit, and I believe we agreed to fix this in the current implementation.
>

That's correct, and it's not a huge change. I can take care of that - and
it is also a prerequisite for the work on splitting L3 in its own plugin.


>
>
> 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.
>>
>>
> Sumit: 8 - 10 AM PST sounds good to me! ;-)
>

I am not terribly keen on sub-team meeting, but if you want to have it I am
happy to participate. I will be unavailable tomorrow, but I am available
friday. Proposed time slot works for me.
Please do IRC, not conf call.


>
>
>> 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/20130501/f9744f27/attachment.html>