Open Stack

Hi Eugene,

The existing code base has already overloaded the term "ServiceType".
Besides the string constants you mentioned, serviceType is also defined in
https://github.com/openstack/quantum/blob/master/quantum/extensions/servicetype.py
.

I think everyone is on the same page that we need to have a single usable
serviceType definition. And now we have an opportunity to re-define
serviceType without incurring too much backward compatibility issue.

As Greg rightfully pointed out, "serviceType" is a tenant-facing
abstraction. Hence, serviceType should consist the attributes that matter
to tenant. In other words, a tenant should be able to pick a serviceType
based on its requirement. That's one of the reasons I believe serviceType
should be a class instead of a string.

Based on the loadbalancer example, only the serviceTypes that are supported
are visible to tenants. Are you proposing the group construct as a way to
achieve filtering? If so, filtering mechanism should be in CLI or Horizon,
but not in service framework. Maybe I mis-understood your example.

Thanks,
Kanzhe


On Fri, May 3, 2013 at 10:44 AM, Regnier, Greg J
<greg.j.regnier at intel.com>wrote:

>  Hi,****
>
> Looking at the model from a tenant’s point of view, the latest simplified
> model/framework proposed by Sumit & Kanzhe makes intuitive sense.****
>
> The basic notions of ‘Service Type’ combined with the ability to create an
> ordered list within the ‘Service Offering’ makes for a very flexible way
> for the tenant to discover and choose the services in a straightforward
> way.  As Kanzhe points out, it could also leads to a straightforward model
> for Service Chaining.****
>
> ** **
>
> Also, the ‘Service Quality’ attribute of a Service Type seems problematic,
> unless it is just a way for a single vendor to denote their
> good/better/best offerings of a given service…****
>
>                 Greg****
>
> ** **
>
> ** **
>
> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *Sent:* Friday, May 03, 2013 9:29 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Quantum][LBaaS] Service type framework:
> todo & cleanup****
>
> ** **
>
> 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****
>
> ** **
>
> _______________________________________________
> 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/20130503/b470daac/attachment.html>