<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Looking at the model from a tenant’s point of view, the latest simplified model/framework proposed by Sumit & Kanzhe makes intuitive sense.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Greg<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eugene Nikanorov [mailto:enikanorov@mirantis.com]
<br>
<b>Sent:</b> Friday, May 03, 2013 9:29 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [Quantum][LBaaS] Service type framework: todo & cleanup<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Kanzhe,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">"Service type" actually is already used in the code in the way I like it to be used, see <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://github.com/openstack/quantum/blob/master/quantum/plugins/common/constants.py#L18">https://github.com/openstack/quantum/blob/master/quantum/plugins/common/constants.py#L18</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">So it's already a predefined set of strings. It is already used to index a plugin in a dictionary of loaded plugins.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So my initial goal was to cleanup possible confusion with <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py#L98">https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py#L98</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">which in my opinion could have a better name. Here "ServiceType" is something like ServiceOffering.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">> Why do we need to group services by their insertion mode? </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">So you have a certain service type, say Loadbalancer, which has 3 implementations (drivers in loadbalancer plugin): Vendor A, Vendor B, Vendor C. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Vendor A supports insertion modes X, Y and Z and quality U, V and W</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Vendor B supports insertion mode X, and quality U and W</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Vendor C supports insertion mode Y and quality V and W</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">With flat ServiceTypeProvider (what you've called ServiceType) you have to specify lots of combinations to express those possible options for a tenant.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">I thought grouping could just reduce amount of those combinations, and what's more important:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">1) You specify vendors (drivers) in config file and i think you want to have minimal amount of information there.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">2) Insertion modes/service quality can be added later if we have proper API, and that would be DB objects rather than configuration info.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think those additional parameters (insertion modes, quality, ServiceOffering/ Service Chains) is a second step after we add ServiceTypeProvider into the framework and API. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">So lets leave these ServiceOfferings for a further discussion.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Thanks,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Eugene.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 3, 2013 at 7:07 PM, Kanzhe Jiang <<a href="mailto:kanzhe.jiang@bigswitch.com" target="_blank">kanzhe.jiang@bigswitch.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Hi Eugene,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regarding "ServiceOffering", I guess the disconnect is the confusion around your definition: "<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Thanks,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Kanzhe</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 3, 2013 at 6:23 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Hi Sumit,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Agree about many-to-many relationship between ServiceOffering and ServiceTypeProvider.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">To me ServiceOffering is services grouped by additional parameter like insertion mode or quality (as I suggested in last email)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also, I'd like to propose a time for meeting: 9 AM PST Monday, 6th May.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Eugene.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 3, 2013 at 9:45 AM, Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi All, Here is an enhanced simplified model. :-) I was brainstorming<br>
with Kanzhe and he had some great input. This should help to satisfy<br>
the multi-service appliance use case as well. The wiki is updated<br>
(<a href="https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework#Simplified_model.2Fframework" target="_blank">https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework#Simplified_model.2Fframework</a>)<br>
but here is a snapshot:<br>
<br>
Service Types:<br>
Each service-type is a unique combination of the following:<br>
String: Uuid (generated)<br>
String: Service-name/category. E.g. LB, FW, etc. (required)<br>
String: Insertion Model (required)<br>
String: Service Type Provider: ServiceType:DriverClass (required),<br>
does not need to be visible to the tenant<br>
String: Service Quality (optional) E.g. Gold, Silver, etc. default: Default<br>
String: Vendor (optional)<br>
Srting: Version (optional)<br>
<br>
* Service Quality is a pre-defined list of strings<br>
* Service-name/categories is a pre-defined list of strings<br>
* Insertion Model is a pre-defined list of strings<br>
<br>
Service Offerings:<br>
A Service offering is an ordered list of one or more service-types.<br>
This accounts for the use cases for discrete services and also<br>
multi-service appliances.<br>
String: Uuid (generated)<br>
String: Service-offering-name (required)<br>
List: service-types (required)<br>
<br>
E.g. [LB-service-type-uuid]<br>
This is a service offering where a user can choose the specific<br>
Loadbalancer service. The plugin and driver for this Loadbalancer<br>
service are captured in the service-type identified by<br>
LB-service-type-uuid.<br>
<br>
E.g. [LB-service-type-uuid, FW-service-type-uuid]<br>
This is a service offering where the provider offers services which<br>
can be potentially realized on a multi-service appliance. As before,<br>
the plugin and driver each of the services are captured in their<br>
respective service-type definitions.<br>
<br>
Resources' relationship:<br>
1 Service-type --> [1..many] Service-offerings<br>
1 Service-offering --> [1..many] Service-types<br>
<br>
Workflow:<br>
1. User queries the list of service-types/offerings<br>
2. User chooses one service-offering. The plugin/backend knows to map<br>
this to a particular provider driver class to realize this resource.<br>
<br>
(if you reached this far, thanks for sticking with this, and apologies<br>
for the long email!)<br>
<br>
Thanks,<br>
~Sumit.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On Thu, May 2, 2013 at 3:54 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
><br>
> Hi again,<br>
><br>
> It's good we're fleshing out options a little bit better.<br>
> 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.<br>
><br>
> 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).<br>
> 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.<br>
><br>
> Salvatore<br>
><br>
> On 2 May 2013 08:42, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
>><br>
>> Salvatore, Kanzhe,<br>
>><br>
>> I don't mind renaming ServiceGroup to ServiceOffering especially if it makes more sense to you :)<br>
>> I've updated the wiki.<br>
><br>
><br>
> As long as it's just naming but we mean the same thing, it's fine.<br>
> the problem would be if we actually mean two different things!<br>
><br>
>><br>
>> 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.<br>
>> Vendor choosing at plugin is analog of scheduling and it seems that we're going to have just too much of flexibility here.<br>
><br>
><br>
> To which argument regarding the workflow are you referring? The one about allowing the plugin to choose among multiple options?<br>
> If yes, I think yours is the right the way to go at the moment.<br>
><br>
><br>
>><br>
>> Another solution to this could be Sumit's suggestion where we merge ServiceTypeProvider with ServiceOffering parameters.<br>
>> In fact as a first implementation step, I'd just leave ServiceTypeProvider as simple as just a pointer to driver class.<br>
><br>
><br>
> 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.<br>
> 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.<br>
> And at the end of the day, a service offering with a single service provider is probably the same thing.<br>
><br>
>><br>
>><br>
>> > Conversely, if we go for directly specifying the service provider type when creating a LB resource (see wiki page), then one will always<br>
>> > be telling to the plugin which driver should be used.<br>
>> > With this approach there would be no space for this use case, and probably also the concept of service group will become irrelevant.<br>
>> My impression was that ServiceOffering is grouping of services around additional parameters such as insertion mode or service quality.<br>
>> So to me it doesn't seem that ServiceOffering will be irrelevant in the case you're talking about.<br>
><br>
><br>
> Cool. I just wanted to make sure of that<br>
>><br>
>><br>
>> Thanks,<br>
>> Eugene.<br>
>><br>
>><br>
>><br>
>> On Thu, May 2, 2013 at 3:50 AM, Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>> wrote:<br>
>>><br>
>>> I too feel that we could potentially simplify the model. Here is a potentially simpler mode/workflow:<br>
>>> <a href="https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework#Simplified_model.2Fframework" target="_blank">
https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework#Simplified_model.2Fframework</a><br>
>>><br>
>>> Please let me know what you guys think.<br>
>>><br>
>>> Thanks,<br>
>>> ~Sumit.<br>
>>><br>
>>><br>
>>> On Wed, May 1, 2013 at 4:38 PM, Kanzhe Jiang <<a href="mailto:kanzhe.jiang@bigswitch.com" target="_blank">kanzhe.jiang@bigswitch.com</a>> wrote:<br>
>>>><br>
>>>> Hi Eugene,<br>
>>>><br>
>>>> 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.<br>
>>>> 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.<br>
>>>><br>
>>>> Kanzhe<br>
>>>><br>
>>>><br>
>>>> On Wed, May 1, 2013 at 4:12 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
>>>>><br>
>>>>> Youcef,<br>
>>>>><br>
>>>>> I seem to recall you already made this point a while ago.<br>
>>>>> 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.<br>
>>>>> Note that this is different from the case where one chooses between vendor A and B by specifying different service offering.<br>
>>>>><br>
>>>>> 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]).<br>
>>>>><br>
>>>>> 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.<br>
>>>>> With this approach there would be no space for this use case, and probably also the concept of service group will become irrelevant.<br>
>>>>><br>
>>>>> Salvatore<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On 1 May 2013 23:09, Youcef Laribi <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Eugene, Salvatore,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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?<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Thanks<br>
>>>>>><br>
>>>>>> Youcef<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> From: Salvatore Orlando [mailto:<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>]<br>
>>>>>> Sent: Wednesday, May 01, 2013 2:19 PM<br>
>>>>>> To: OpenStack Development Mailing List<br>
>>>>>> Subject: Re: [openstack-dev] [Quantum][LBaaS] Service type framework: todo & cleanup<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Eugene,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> I quickly went through your wiki and I think most of it makes total sense to me.<br>
>>>>>><br>
>>>>>> I would just consider renaming "Service Groups" to "Service Offering" because it's less ambiguous.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> And as you know, steering the discussion onto service insertion kills productivity.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On 1 May 2013 21:32, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Salvatore, folks,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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:<br>
>>>>>><br>
>>>>>> <a href="https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework" target="_blank">
https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> May be if everyone is ok with this proposal then our meeting will be short (if we even need one) :)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> Eugene.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Wed, May 1, 2013 at 6:15 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Eugene,<br>
>>>>>><br>
>>>>>> I did not see this message and I replied on the other post.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> You've set the discussion on the right tracks with your first email.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Salvatore<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On 1 May 2013 15:04, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
>>>>>><br>
>>>>>> So folks,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> How about meet tomorrow, Thursday, 10 AM PST at #quantum-lbaas and discuss these things?<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> Eugene.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Tue, Apr 30, 2013 at 8:31 PM, Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi Eugene,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> ~Sumit.<br>
>>>>>><br>
>>>>>> On Tue, Apr 30, 2013 at 8:34 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi folks,<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> One of the major features that we need to implement during Havana (H-1 at best) is true flexible multivendor support.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Let's start with what we have on service types today:<br>
>>>>>><br>
>>>>>> 1) Description of the feature: <a href="https://wiki.openstack.org/wiki/Quantum/ServiceInsertion" target="_blank">
https://wiki.openstack.org/wiki/Quantum/ServiceInsertion</a><br>
>>>>>><br>
>>>>>> 2) Code: <a href="https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py" target="_blank">
https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py</a><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> I'd like to set service insertion problem aside and focus on service types as a way to choose vendor.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> So, on terminology side we have the following enitities (from code and docs):<br>
>>>>>><br>
>>>>>> - Service Type - defines a set of service providers (plugins:drivers)<br>
>>>>>><br>
>>>>>> - Service Definition - defines one service provider<br>
>>>>>><br>
>>>>>> - Service Class - a type of service (?!) (LB, FW, VPN)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 1) So, first of all terminology seems to be quite confusing, especially word "type" is overloaded.<br>
>>>>>><br>
>>>>>> I think we need to propose better names for the these entities just to simplify our thinking about the integration with services.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> So, my proposal would be:<br>
>>>>>><br>
>>>>>> - Service Type - LB, FW, VPN<br>
>>>>>><br>
>>>>>> - Service Type Provider - defines one service provider (former Service Definition) (alt: Service Type Definition)<br>
>>>>>><br>
>>>>>> - Service Group - what used to be Service Type. (alt: Service Set, ??)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Sumit: How about a top level "service_type" class (consistent with current definition) with attributes like:<br>
>>>>>><br>
>>>>>> - Category, e.g. LB, FW, VPN<br>
>>>>>><br>
>>>>>> - Vendor, e.g. XYZ<br>
>>>>>><br>
>>>>>> - 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)<br>
>>>>>><br>
>>>>>> - Provider, name of the class which implements this service (one per type as you suggest later)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Until agreed, I'll use old terminology.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 2) The relationship between Service Types and Service Definitions.<br>
>>>>>><br>
>>>>>> It is not obvious (nowhere stated or enforced) but Service Type must have just one Service Definition of the same Service Class,<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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).<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 3) API calls dispatching. The most important question: whether or not to support multiple plugins per Service Class.<br>
>>>>>><br>
>>>>>> In other words, whether to have several Service plugins (several lbaas plugins, for ex) loaded simultaneosly.<br>
>>>>>><br>
>>>>>> My opinion is that we don't need that as multi-vendor support could be implemented more simple plugin-side drivers.<br>
>>>>>><br>
>>>>>> To make this shorter, I'll skip explanation for now.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> So in order to move forward I'd suggest we have a meeting with the following agenda:<br>
>>>>>><br>
>>>>>> 1. Terminology<br>
>>>>>><br>
>>>>>> 2. Service type framework refactoring.<br>
>>>>>><br>
>>>>>> 3. API calls dispatching: hints and control flow.<br>
>>>>>><br>
>>>>>> I'll prepare some suggestions/diagrams about this.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> We could have a meeting someday this week at 8:00 - 10:00 AM PST, late evening PST will also work for me.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Sumit: 8 - 10 AM PST sounds good to me! ;-)<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> Eugene.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list<br>
>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Kanzhe Jiang<br>
>>>> MTS at BigSwitch<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Kanzhe Jiang<o:p></o:p></p>
<div>
<p class="MsoNormal">MTS at BigSwitch<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>