Open Stack

Eugene,
I did not see this message and I replied on the other post.
I will not be available tomorrow between 6AM PST and 1PM PST. Friday would
work for me, but honestly I think we might want to flesh out ideas and
terminology a little bit better offline before going into a meeting; I
think having a clearer picture will boost the productivity of the meeting.

You've set the discussion on the right tracks with your first email.

Salvatore


On 1 May 2013 15:04, Eugene Nikanorov <enikanorov at mirantis.com> wrote:

> 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.
>>>
>>
>>
>
> _______________________________________________
> 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/f6a1afae/attachment.html>