<div dir="ltr">Hi, this is a follow up of the todays' LBaaS meeting held on #quantum-lbaas.<div><br></div><div style>Agenda:</div><div style>1. ServiceType framework</div><div style>2. Service source file locations</div>
<div style>3. Multivendor support</div><div style>4. NFV </div><div style>5. Regular meeting</div><div style><br></div><div style>1. ServiceType framework</div><div style>Agreed on the following:</div><div style>- ServiceType is the name of the entity consisting of </div>
<div style>(uuid, service_class, plugin:driver, vendor (opt), version (opt))</div><div style>This is an essential entity with minimal info needed for multivendor support.</div><div style>- Extra parameters include: insertion mode, service quality.</div>
<div style><br></div><div style>Action item: Sumit to prepare workflow with additional parameters (ins. mode, quality) and entities (ServiceOffering, ServiceChain, etc).</div><div style>Workflow design should be a separate discussion.</div>
<div style><br></div><div style>Action item: Eugene to refactor current ServiceType framework to comply with what was decided.</div><div style><br></div><div style>2. Service source file locations (related gerrit <a href="https://review.openstack.org/#/c/28257/">https://review.openstack.org/#/c/28257/</a> )</div>
<div style>Agreed on making two changes:</div><div style>- move all lbaas-related implementation files to plugins/services/agent_loadbalancer</div><div style>(db plugin goes to services/agent_loadbalancer/db)</div><div style>
- rename agent_loadbalancer to loadbalancer to indicate that we're going to have multivendor solution</div><div style><br></div><div style>Remaining question:</div><div style>whether to move whole services directory one level up.</div>
<div style>That could shorten import paths a bit and also it's a good time to make such change before services directory is not very populated.</div><div style><br></div><div style>3. Multivendor support</div><div style>
Was not discussed.</div><div style>There are two patches on review:</div><div style>splitting reference implementation into plugin and plugin driver: <a href="https://review.openstack.org/#/c/28289/">https://review.openstack.org/#/c/28289/</a></div>
<div style><br></div><div style><span style="color:rgb(0,0,0);font-family:'Arial Unicode MS',Arial,sans-serif;white-space:nowrap">"Blueprint multi-vendor-support-for-lbaas-step0" </span><a href="https://review.openstack.org/#/c/28245">https://review.openstack.org/#/c/28245</a><br>
</div><div style><br></div><div style>4. Network Function Virtualization.</div><div style>There's a concern that this blueprint is trying to address the problem that is already is being solved. </div><div style><a href="https://blueprints.launchpad.net/quantum/+spec/nfv-and-network-service-chain-implementation">https://blueprints.launchpad.net/quantum/+spec/nfv-and-network-service-chain-implementation</a></div>
<div style>This is not quite related to LBaaS, however there are plans to implement "device inventory" module, which is needed for LBaaS and could be utilized by other services as well.</div><div style>That overlaps with what is proposed in NFV.</div>
<div style><br></div><div style>5. Regular LBaaS meeting.</div><div style>Waiting for Mark McClain opinion.</div><div style><br></div><div style>Thanks,</div><div style>Eugene.<br></div></div>