<div dir="ltr">Hi folks,<div><br></div><div style>One of the major features that we need to implement during Havana (H-1 at best) is true flexible multivendor support.</div><div style>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 style><br></div><div style>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 style><br></div><div style>Let's start with what we have on service types today:</div>
<div style>1) Description of the feature: <a href="https://wiki.openstack.org/wiki/Quantum/ServiceInsertion">https://wiki.openstack.org/wiki/Quantum/ServiceInsertion</a></div><div style>2) Code: <a href="https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py">https://github.com/openstack/quantum/blob/master/quantum/db/servicetype_db.py</a></div>
<div style>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 style><br></div><div style><b>I'd like to set service insertion problem aside and focus on service types as a way to choose vendor.</b></div>
<div style><br></div><div style>So, on terminology side we have the following enitities (from code and docs):</div><div style>- Service Type - defines a set of service providers (plugins:drivers)</div><div style>- Service Definition - defines one service provider</div>
<div style>- Service Class - a type of service (?!) (LB, FW, VPN)</div><div style><br></div><div style>1) So, first of all terminology seems to be quite confusing, especially word "type" is overloaded.</div><div style>
I think we need to propose better names for the these entities just to simplify our thinking about the integration with services.</div><div style><br></div><div style>So, my proposal would be: </div><div style>- Service Type - LB, FW, VPN</div>
<div style>- Service Type Provider - defines one service provider (former Service Definition) (alt: Service Type Definition)</div><div style>- Service Group - what used to be Service Type. (alt: Service Set, ??)</div><div style>
<br></div><div style>Until agreed, I'll use old terminology.</div><div style><br></div><div style>2) The relationship between Service Types and Service Definitions.<br></div><div style>It is not obvious (nowhere stated or enforced) but Service Type must have just one Service Definition of the same Service Class,</div>
<div style>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 style><br></div><div style>3) API calls dispatching. The most important question: whether or not to support multiple plugins per Service Class.</div>
<div style>In other words, whether to have several Service plugins (several lbaas plugins, for ex) loaded simultaneosly.</div><div style>My opinion is that we don't need that as multi-vendor support could be implemented more simple plugin-side drivers.</div>
<div style>To make this shorter, I'll skip explanation for now.</div><div style><br></div><div style>So in order to move forward I'd suggest we have a meeting with the following agenda:</div><div style>1. Terminology</div>
<div style>2. Service type framework refactoring.</div><div style>3. API calls dispatching: hints and control flow.</div><div style>I'll prepare some suggestions/diagrams about this.</div><div style><br></div><div style>
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 style><br></div><div style>Thanks,</div><div style>Eugene.</div></div>