<div dir="ltr">Some comments inline.<div>Thanks for starting this discussion.</div><div>Hopefully this time we'll manage to convert thought into code in a reasonable time.</div><div><br></div><div>Salvatore<br><div class="gmail_extra">
<br><br><div class="gmail_quote">On 30 April 2013 17:31, Sumit Naiksatam <span dir="ltr"><<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Eugene,<div><br></div><div>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.</div>

<div><br></div><div>~Sumit.<br><br><div class="gmail_quote"><div class="im">On Tue, Apr 30, 2013 at 8:34 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi folks,<div><br></div><div>One of the major features that we need to implement during Havana (H-1 at best) is true flexible multivendor support.</div>

<div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Let's start with what we have on service types today:</div>


<div>1) Description of the feature: <a href="https://wiki.openstack.org/wiki/Quantum/ServiceInsertion" target="_blank">https://wiki.openstack.org/wiki/Quantum/ServiceInsertion</a></div><div>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></div>


<div>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.</div></div></blockquote></div></div></div></blockquote><div><br></div><div style>Agreed; the framework was conceived since it looked like 1000 different drivers and plugins were going to be pushed for Grizzly.</div>
<div style>That did not go that way, and using a service type where you have only a single type of service does not make a lot of sense.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><b>I'd like to set service insertion problem aside and focus on service types as a way to choose vendor.</b></div>
</div></blockquote></div></div></div></blockquote><div><br></div><div style>I totally agree on this point; still this is too a kind of 'service insertion' or 'selection' if you want not to create confusion.</div>
<div style>From past experience, confusion on terminology is the 1st reason for disagreement which slows down progress due to infinite cycles of discussion.</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">

<div><br></div><div>So, on terminology side we have the following enitities (from code and docs):</div><div>- Service Type - defines a set of service providers (plugins:drivers)</div><div>- Service Definition - defines one service provider</div>


<div>- Service Class - a type of service (?!) (LB, FW, VPN)</div></div></blockquote><div></div></div></div></div></blockquote><div><br></div><div style>Pretty much that's it. It very simple: a servite type is a list of service definition. Each service definition has a service class (whose semantics are exactly the one you listed), a plugin, and a driver.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div>
<div>1) So, first of all terminology seems to be quite confusing, especially word "type" is overloaded.</div><div>
I think we need to propose better names for the these entities just to simplify our thinking about the integration with services.</div><div><br></div></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div></div><div>So, my proposal would be: </div><div>- Service Type - LB, FW, VPN</div>
<div>- Service Type Provider - defines one service provider (former Service Definition) (alt: Service Type Definition)</div><div>- Service Group - what used to be Service Type. (alt: Service Set, ??)</div></div></blockquote>
</div></div></div></blockquote><div><br></div><div style>I agree with the overlap on type. This is why I used 'Class' I am happy with renaming class to type. Service Group is probably still ambiguos, and I will go with Service Offering.</div>
<div style>Yes, I am copying Cloudstack here if you're wondering.</div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>
<br></div></div></blockquote><div><br></div></div><div>Sumit: How about a top level "service_type" class (consistent with current definition) with attributes like:</div><div>- Category, e.g. LB, FW, VPN</div><div>
- Vendor, e.g. XYZ</div>
<div>- 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)</div><div>- Provider, name of the class which implements this service (one per type as you suggest later)</div>
</div></div></blockquote><div><br></div><div style>Not sure the vendor is needed; and we can rediscuss the insertion mode once the terminology is clarified. Your proposal make sense, but I am with Eugene here on focusing on multi-vendor selection first.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Until agreed, I'll use old terminology.</div><div><br></div><div>2) The relationship between Service Types and Service Definitions.<br>

</div><div>It is not obvious (nowhere stated or enforced) but Service Type must have just one Service Definition of the same Service Class,</div>
<div>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.</div></div></blockquote></div></div></div></blockquote>
<div><br></div><div style>We were wishing to have multiple 'plugins' for the same 'service class'. This is not going to happen not even for havana. I would keep the db model flexibile and enforce the constraint in the API.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div></div></blockquote><div><br></div>
</div><div>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).</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>3) API calls dispatching. The most important question: whether or not to support multiple plugins per Service Class.</div>


<div>In other words, whether to have several Service plugins (several lbaas plugins, for ex) loaded simultaneosly.</div><div>My opinion is that we don't need that as multi-vendor support could be implemented more simple plugin-side drivers.</div>


<div>To make this shorter, I'll skip explanation for now.</div></div></blockquote></div></div></div></blockquote><div><br></div><div style>I agree with you; this is a need we might have in the future, and non-negligible infrastructure changes are needed.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></blockquote><div><br></div><div style>That's correct, and it's not a huge change. I can take care of that - and it is also a prerequisite for the work on splitting L3 in its own plugin.</div><div style>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="im">
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>So in order to move forward I'd suggest we have a meeting with the following agenda:</div>

<div>1. Terminology</div>
<div>2. Service type framework refactoring.</div><div>3. API calls dispatching: hints and control flow.</div><div>I'll prepare some suggestions/diagrams about this.</div><div><br></div><div>
We could have a meeting someday this week at 8:00 - 10:00 AM PST, late evening PST will also work for me.</div><div><br></div></div></blockquote><div><br></div></div><div>Sumit: 8 - 10 AM PST sounds good to me! ;-)</div>
</div></div></blockquote><div><br></div><div style>I am not terribly keen on sub-team meeting, but if you want to have it I am happy to participate. I will be unavailable tomorrow, but I am available friday. Proposed time slot works for me.</div>
<div style>Please do IRC, not conf call.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Thanks,</div><div>Eugene.</div></div>
</blockquote></div><br></div>
<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><br>
<br></blockquote></div><br></div></div></div>