Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/dd9d72c7/attachment.html>