<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";}
h4
{mso-style-priority:9;
mso-style-link:"Heading 4 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
font-weight:bold;}
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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.Heading4Char
{mso-style-name:"Heading 4 Char";
mso-style-priority:9;
mso-style-link:"Heading 4";
font-family:"Times New Roman","serif";
font-weight:bold;}
span.mw-headline
{mso-style-name:mw-headline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.mw-editsection
{mso-style-name:mw-editsection;}
.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'>Eugene, Salvatore,<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'>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?<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'>Thanks<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Youcef<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><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"'> Salvatore Orlando [mailto:sorlando@nicira.com] <br><b>Sent:</b> Wednesday, May 01, 2013 2:19 PM<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>Eugene,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I quickly went through your wiki and I think most of it makes total sense to me.<o:p></o:p></p></div><div><p class=MsoNormal>I would just consider renaming "Service Groups" to "Service Offering" because it's less ambiguous.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal>And as you know, steering the discussion onto service insertion kills productivity.<o:p></o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><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 1 May 2013 21:32, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Salvatore, folks,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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:<o:p></o:p></p></div><div><p class=MsoNormal><a href="https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework" target="_blank">https://wiki.openstack.org/wiki/Quantum/ServiceTypeFramework</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>May be if everyone is ok with this proposal then our meeting will be short (if we even need one) :)<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><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, May 1, 2013 at 6:15 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><div><p class=MsoNormal>Eugene,<o:p></o:p></p></div><p class=MsoNormal>I did not see this message and I replied on the other post.<o:p></o:p></p><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>You've set the discussion on the right tracks with your first email.<o:p></o:p></p></div></div><div><p class=MsoNormal><span style='color:#888888'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:#888888'>Salvatore<o:p></o:p></span></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><div><p class=MsoNormal>On 1 May 2013 15:04, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<o:p></o:p></p></div></div></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><div><div><p class=MsoNormal>So folks,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>How about meet tomorrow, Thursday, 10 AM PST at #quantum-lbaas and discuss these things?<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><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Apr 30, 2013 at 8:31 PM, Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><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>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>~Sumit.<o:p></o:p></p><div><div><div><p class=MsoNormal>On Tue, Apr 30, 2013 at 8:34 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>Hi folks,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>One of the major features that we need to implement during Havana (H-1 at best) is true flexible multivendor support.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Let's start with what we have on service types today:<o:p></o:p></p></div><div><p class=MsoNormal>1) Description of the feature: <a href="https://wiki.openstack.org/wiki/Quantum/ServiceInsertion" target="_blank">https://wiki.openstack.org/wiki/Quantum/ServiceInsertion</a><o:p></o:p></p></div><div><p class=MsoNormal>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><o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><div><p class=MsoNormal><b>I'd like to set service insertion problem aside and focus on service types as a way to choose vendor.</b><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><div><p class=MsoNormal>So, on terminology side we have the following enitities (from code and docs):<o:p></o:p></p></div><div><p class=MsoNormal>- Service Type - defines a set of service providers (plugins:drivers)<o:p></o:p></p></div><div><p class=MsoNormal>- Service Definition - defines one service provider<o:p></o:p></p></div><div><p class=MsoNormal>- Service Class - a type of service (?!) (LB, FW, VPN)<o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>1) So, first of all terminology seems to be quite confusing, especially word "type" is overloaded.<o:p></o:p></p></div><div><div><p class=MsoNormal>I think we need to propose better names for the these entities just to simplify our thinking about the integration with services.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>So, my proposal would be: <o:p></o:p></p></div><div><p class=MsoNormal>- Service Type - LB, FW, VPN<o:p></o:p></p></div><div><p class=MsoNormal>- Service Type Provider - defines one service provider (former Service Definition) (alt: Service Type Definition)<o:p></o:p></p></div><div><p class=MsoNormal>- Service Group - what used to be Service Type. (alt: Service Set, ??)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><div><div><p class=MsoNormal>Sumit: How about a top level "service_type" class (consistent with current definition) with attributes like:<o:p></o:p></p></div><div><p class=MsoNormal>- Category, e.g. LB, FW, VPN<o:p></o:p></p></div><div><p class=MsoNormal>- Vendor, e.g. XYZ<o:p></o:p></p></div><div><p class=MsoNormal>- 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)<o:p></o:p></p></div><div><p class=MsoNormal>- Provider, name of the class which implements this service (one per type as you suggest later)<o:p></o:p></p></div></div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>Until agreed, I'll use old terminology.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2) The relationship between Service Types and Service Definitions.<o:p></o:p></p></div><div><p class=MsoNormal>It is not obvious (nowhere stated or enforced) but Service Type must have just one Service Definition of the same Service Class,<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><div><div><p class=MsoNormal>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).<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>3) API calls dispatching. The most important question: whether or not to support multiple plugins per Service Class.<o:p></o:p></p></div><div><p class=MsoNormal>In other words, whether to have several Service plugins (several lbaas plugins, for ex) loaded simultaneosly.<o:p></o:p></p></div><div><p class=MsoNormal>My opinion is that we don't need that as multi-vendor support could be implemented more simple plugin-side drivers.<o:p></o:p></p></div><div><p class=MsoNormal>To make this shorter, I'll skip explanation for now.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>So in order to move forward I'd suggest we have a meeting with the following agenda:<o:p></o:p></p></div><div><p class=MsoNormal>1. Terminology<o:p></o:p></p></div><div><p class=MsoNormal>2. Service type framework refactoring.<o:p></o:p></p></div><div><p class=MsoNormal>3. API calls dispatching: hints and control flow.<o:p></o:p></p></div><div><p class=MsoNormal>I'll prepare some suggestions/diagrams about this.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We could have a meeting someday this week at 8:00 - 10:00 AM PST, late evening PST will also work for me.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div></div><div><div><p class=MsoNormal>Sumit: 8 - 10 AM PST sounds good to me! ;-)<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal>Eugene.<o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>_______________________________________________<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></blockquote></div><p class=MsoNormal><o:p> </o:p></p></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></blockquote></div><p class=MsoNormal><o:p> </o:p></p></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></div></div></body></html>