Open Stack

I too feel that we could potentially simplify the model. Here is a
potentially simpler mode/workflow:
https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework#Simplified_model.2Fframework

Please let me know what you guys think.

Thanks,
~Sumit.

On Wed, May 1, 2013 at 4:38 PM, Kanzhe Jiang <kanzhe.jiang at bigswitch.com>wrote:

> Hi Eugene,
>
> Thank you for the serviceType proposal. ServiceType, ServiceTypeProvider,
> and InsertionMode make lots of sense. However, I have a hard time to
> capture the meaning of ServiceGroup.
> Salvatore's suggestion seems to be more that just a name change if I
> understood correctly. ServiceOffering is a top-level object that consists
> of serviceType, serviceTypeProvider and insertionMode. The user/tenant
> workflow then becomes a one-step process, picking a serviceOffering from an
> available list. A logic service is then created based on the selected
> serviceOffering.
>
> Kanzhe
>
>
> On Wed, May 1, 2013 at 4:12 PM, Salvatore Orlando <sorlando at nicira.com>wrote:
>
>> Youcef,
>>
>> I seem to recall you already made this point a while ago.
>> I've tried to look back at old email threads, and it seems the use case
>> for a scenario like the one you describe would be when a given service
>> type/group/offering can be either be realized to provider 'a' or 'b', in
>> this case it would be the plugin to decide which driver to use, according
>> to some plugin-specific logic that is beyond the scope of this discussion.
>> Note that this is different from the case where one chooses between
>> vendor A and B by specifying different service offering.
>>
>> If I got your use case correctly, then I'm ok with designing the feature
>> in this way (actually I would have something like "LB": [VendorXDriver,
>> VendorYDriver]).
>>
>> Conversely, if we go for directly specifying the service provider type
>> when creating a LB resource (see wiki page), then one will always be
>> telling to the plugin which driver should be used.
>> With this approach there would be no space for this use case, and
>> probably also the concept of service group will become irrelevant.
>>
>> Salvatore
>>
>>
>>
>> On 1 May 2013 23:09, Youcef Laribi <Youcef.Laribi at eu.citrix.com> wrote:
>>
>>> Eugene, Salvatore,****
>>>
>>> ** **
>>>
>>> To clarify my understanding of the concept of ServiceGroup (or
>>> ServiceOffering to use Salvatore’s terminology), are you allowing for the
>>> same ServiceType (e.g. LB) to be offered by multiple vendors  (e.g a
>>> ServiceOffering could be { “LB”:”LBVendorXDriver”, “FW”:”FWVendorADriver”,
>>> “LB”:”LBVendorYDriver”} ? And in this case is “step 2” in the “workflow for
>>> a user” section about choosing one vendor for each service type if there is
>>> more than one?****
>>>
>>> ** **
>>>
>>> Thanks****
>>>
>>> Youcef****
>>>
>>> ****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
>>> *Sent:* Wednesday, May 01, 2013 2:19 PM
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] [Quantum][LBaaS] Service type framework:
>>> todo & cleanup****
>>>
>>> ** **
>>>
>>> Eugene,****
>>>
>>> ** **
>>>
>>> I quickly went through your wiki and I think most of it makes total
>>> sense to me.****
>>>
>>> I would just consider renaming "Service Groups" to "Service Offering"
>>> because it's less ambiguous.****
>>>
>>> This concept, at least for reading, is made available to tenant.
>>> Exposing it as an "Offering" of services that can be deployed makes more
>>> sense.****
>>>
>>> ** **
>>>
>>> I see you also have two todos: for the first, I'd say let's keep it open
>>> to future implementation with multiple plugins (if we don't do that, we
>>> might end up in a pickle), for the second, I'd say it's a cool feature, but
>>> probably not worth the hassle. ****
>>>
>>> ** **
>>>
>>> I would keep the insertion model out for now; not because I do not agree
>>> with it, but because we might incur the same problem we had with Service
>>> Type, and also the LB API.****
>>>
>>> Since we did it without a backing implementation, we then had to tweak
>>> it. We can always augment the service type once the service
>>> insertion/chaining framework will be ready.****
>>>
>>> And as you know, steering the discussion onto service insertion kills
>>> productivity.****
>>>
>>> I like the idea anyway - and we already proposed to include it into the
>>> servicetypespec in Grizzly - for instance it could be used to say whether
>>> the corresponding implementation is backed by a service VM, an ADC with
>>> context, or whether it's a physical device attached at L2, and so on. **
>>> **
>>>
>>> ** **
>>>
>>> On the REST call dispatching section, I don't see anything wrong with
>>> your idea, the only change I would propose is that when you create a VIP
>>> you specify the service offering, not the service provider. You do not want
>>> to expose that kind of detail.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> On 1 May 2013 21:32, Eugene Nikanorov <enikanorov at mirantis.com> wrote:**
>>> **
>>>
>>> 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****
>>>
>>> ** **
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Kanzhe Jiang
> MTS at BigSwitch
>
> _______________________________________________
> 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/1567e030/attachment.html>