Open Stack

Kanzhe,

"Service type" actually is already used in the code in the way I like it to
be used, see
https://github.com/openstack/quantum/blob/master/quantum/plugins/common/constants.py#L18
So it's already a predefined set of strings. It is already used to index a
plugin in a dictionary of loaded plugins.

So my initial goal was to cleanup possible confusion with
https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py#L98
which in my opinion could have a better name. Here "ServiceType" is
something like ServiceOffering.

> Why do we need to group services by their insertion mode?
So you have a certain service type, say Loadbalancer, which has 3
implementations (drivers in loadbalancer plugin): Vendor A, Vendor B,
Vendor C.
Vendor A supports insertion modes X, Y and Z and quality U, V and W
Vendor B supports insertion mode X, and quality U and W
Vendor C supports insertion mode Y and quality V and W
With flat ServiceTypeProvider (what you've called ServiceType) you have to
specify lots of combinations to express those possible options for a tenant.
I thought grouping could just reduce amount of those combinations, and
what's more important:
1) You specify vendors (drivers) in config file and i think you want to
have minimal amount of information there.
2) Insertion modes/service quality can be added later if we have proper
API, and that would be DB objects rather than configuration info.

I think those additional parameters (insertion modes, quality,
ServiceOffering/ Service Chains) is a second step after we add
ServiceTypeProvider into the framework and API.

So lets leave these ServiceOfferings for a further discussion.

Thanks,
Eugene.


On Fri, May 3, 2013 at 7:07 PM, Kanzhe Jiang <kanzhe.jiang at bigswitch.com>wrote:

> Hi Eugene,
>
> In Sumit's proposal, serviceTypeProvider is the same as your original one.
> I think it is the best to determine whether the serviceType should be a
> string or an object by considering how a serviceType would be used. One use
> case is that the plugin should be able to determine the driver for a given
> serviceType. Another one is a tenant should be able to list all "LB"
> serviceTypes and pick one based on either quality, its favorite provider,
> etc. Making serviceType a string seems trivialize its definition a bit too
> much.
>
> Regarding "ServiceOffering", I guess the disconnect is the confusion
> around your definition: "ServiceOffering is services grouped by
> additional parameter like insertion mode or quality". Why do we need to
> group services by their insertion mode? The one thing that I can think of
> is for routerInserted services. If I understand correctly, grouping
> routerInserted services can be used to express a router with multi-service
> capability. However, the grouping doesn't work for any other insertion
> mode. For example, grouping L2-inserted services into an offering doesn't
> make much sense.
>
> Sumit's proposal of using serviceOffering to group services would satisfy
> routerInserted services too. Yes, the serviceOffering could be used later
> for service chaining. So we might be able to address both needs with this
> proposal.
>
> Thanks,
> Kanzhe
>
>
> On Fri, May 3, 2013 at 6:23 AM, Eugene Nikanorov <enikanorov at mirantis.com>wrote:
>
>> Hi Sumit,
>>
>> I see that meaning of terms service-type/service type provider is still
>> floating and the meaning I've proposed went to service-name/catategory. I'd
>> object against introducing more notions here.
>>
>> Agree about many-to-many relationship between ServiceOffering and
>> ServiceTypeProvider.
>> But I don't get the purpose of ServiceOffering entity in the form you're
>> proposing. It looks more like a service chain with it's ordered list of
>> services.
>> To me ServiceOffering is services grouped by additional parameter like
>> insertion mode or quality (as I suggested in last email)
>>
>> Also, I'd like to propose a time for meeting: 9 AM PST Monday, 6th May.
>>
>> Thanks,
>> Eugene.
>>
>>
>> On Fri, May 3, 2013 at 9:45 AM, Sumit Naiksatam <sumitnaiksatam at gmail.com
>> > wrote:
>>
>>> Hi All, Here is an enhanced simplified model. :-) I was brainstorming
>>> with Kanzhe and he had some great input. This should help to satisfy
>>> the multi-service appliance use case as well. The wiki is updated
>>> (
>>> https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework#Simplified_model.2Fframework
>>> )
>>> but here is a snapshot:
>>>
>>> Service Types:
>>> Each service-type is a unique combination of the following:
>>>   String: Uuid (generated)
>>>   String: Service-name/category. E.g. LB, FW, etc. (required)
>>>   String: Insertion Model (required)
>>>   String: Service Type Provider: ServiceType:DriverClass (required),
>>> does not need to be visible to the tenant
>>>   String: Service Quality (optional) E.g. Gold, Silver, etc. default:
>>> Default
>>>   String: Vendor (optional)
>>>   Srting: Version (optional)
>>>
>>>    * Service Quality is a pre-defined list of strings
>>>    * Service-name/categories is a pre-defined list of strings
>>>    * Insertion Model is a pre-defined list of strings
>>>
>>> Service Offerings:
>>> A Service offering is an ordered list of one or more service-types.
>>> This accounts for the use cases for discrete services and also
>>> multi-service appliances.
>>>   String: Uuid (generated)
>>>   String: Service-offering-name (required)
>>>   List: service-types (required)
>>>
>>> E.g. [LB-service-type-uuid]
>>> This is a service offering where a user can choose the specific
>>> Loadbalancer service. The plugin and driver for this Loadbalancer
>>> service are captured in the service-type identified by
>>> LB-service-type-uuid.
>>>
>>> E.g. [LB-service-type-uuid, FW-service-type-uuid]
>>> This is a service offering where the provider offers services which
>>> can be potentially realized on a multi-service appliance. As before,
>>> the plugin and driver each of the services are captured in their
>>> respective service-type definitions.
>>>
>>> Resources' relationship:
>>> 1 Service-type --> [1..many] Service-offerings
>>> 1 Service-offering --> [1..many] Service-types
>>>
>>> Workflow:
>>> 1. User queries the list of service-types/offerings
>>> 2. User chooses one service-offering. The plugin/backend knows to map
>>> this to a particular provider driver class to realize this resource.
>>>
>>> (if you reached this far, thanks for sticking with this, and apologies
>>> for the long email!)
>>>
>>> Thanks,
>>> ~Sumit.
>>>
>>> On Thu, May 2, 2013 at 3:54 AM, Salvatore Orlando <sorlando at nicira.com>
>>> wrote:
>>> >
>>> > Hi again,
>>> >
>>> > It's good we're fleshing out options a little bit better.
>>> > I will take a better look at Sumit's alternative proposal. At a first
>>> glance it looks like it's just making the service type flat, removing the
>>> need for grouping, but I'd rather have a better look at that.
>>> >
>>> > And then again, I would pledge to adhere to the initial goal fixed by
>>> Eugene: allowing the selection of a specific driver, in a vendor-agnostic
>>> way (I added the last bit).
>>> > Service insertion models can come later in the process. I don't think
>>> what we currently have in the source code tree would leverage them anyway.
>>> >
>>> > Salvatore
>>> >
>>> > On 2 May 2013 08:42, Eugene Nikanorov <enikanorov at mirantis.com> wrote:
>>> >>
>>> >> Salvatore, Kanzhe,
>>> >>
>>> >> I don't mind renaming ServiceGroup to ServiceOffering especially if
>>> it makes more sense to you :)
>>> >> I've updated the wiki.
>>> >
>>> >
>>> > As long as it's just naming but we mean the same thing, it's fine.
>>> > the problem would be if we actually mean two different things!
>>> >
>>> >>
>>> >> Regarding the workflow: I specifically made this a two step process
>>> to avoid taking decision at plugin (which could be additional complex
>>> problem) and put it onto User.
>>> >> Vendor choosing at plugin is analog of scheduling and it seems that
>>> we're going to have just too much of flexibility here.
>>> >
>>> >
>>> > To which argument regarding the workflow are you referring? The one
>>> about allowing the plugin to choose among multiple options?
>>> > If yes, I think yours is the right the way to go at the moment.
>>> >
>>> >
>>> >>
>>> >> Another solution to this could be Sumit's suggestion where we merge
>>> ServiceTypeProvider with ServiceOffering parameters.
>>> >> In fact as a first implementation step, I'd just leave
>>> ServiceTypeProvider as simple as just a pointer to driver class.
>>> >
>>> >
>>> > Sumit is actually proposing a sort of linearization. This flat model
>>> is ok, but I think allowing for grouping might be better since many people
>>> are already working on service appliance which offer multiple advanced
>>> services.
>>> > Also, we have committed to split L3 functionality from the core
>>> plugin. This means that for Havana we may add also a L3 service provider to
>>> this list.
>>> > And at the end of the day, a service offering with a single service
>>> provider is probably the same thing.
>>> >
>>> >>
>>> >>
>>> >> > 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.
>>> >> My impression was that ServiceOffering is grouping of services around
>>> additional parameters such as insertion mode or service quality.
>>> >> So to me it doesn't seem that ServiceOffering will be irrelevant in
>>> the case you're talking about.
>>> >
>>> >
>>> > Cool. I just wanted to make sure of that
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Eugene.
>>> >>
>>> >>
>>> >>
>>> >> On Thu, May 2, 2013 at 3:50 AM, Sumit Naiksatam <
>>> sumitnaiksatam at gmail.com> wrote:
>>> >>>
>>> >>> 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
>>> >>>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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/20130503/c4da10fc/attachment-0001.html>