Open Stack

Salvatore, folks,

Friday also works for me. To have something concrete to discuss, I've
created a page with a summary of the ideas in my first email:
https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework

May be if everyone is ok with this proposal then our meeting will be short
(if we even need one) :)

Thanks,
Eugene.



On Wed, May 1, 2013 at 6:15 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20130502/4b8587aa/attachment.html>