Open Stack

So folks,

How about meet tomorrow, Thursday, 10 AM PST at #quantum-lbaas and discuss
these things?

Thanks,
Eugene.


On Tue, Apr 30, 2013 at 8:31 PM, 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.
>>
>> *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, ??)
>>
>>
> 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)
>
> 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.
>>
>>
> 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.
>>
>>
> 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.
>
>
> 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! ;-)
>
>
>> Thanks,
>> Eugene.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/62a021d5/attachment.html>