Hi, <div><br></div><div>I would like to resume discussion about managing service appliances and scheduling resource objects to them. Under 'resource object' I mean vip in case of lbaas (vpn_connections in case of vpnaas). Under 'appliance' I mean machine/process where service runs. It can be:</div>
<div> 1) on-host process - ex. haproxy as process on network controller or dedicated node with running haproxy</div><div> 2) VM running on compute node</div><div> 3) physical appliance</div><div><br></div><div>The current proposal is to introduce 'device inventory' module (<a href="https://blueprints.launchpad.net/quantum/+spec/device-inventory-management">https://blueprints.launchpad.net/quantum/+spec/device-inventory-management</a>). The module is designed to be shared between all services (not only lbaas). Its main purpose is storing available appliances and their parameters to choose to which instance logical configuration will be deployed. </div>
<div><br></div><div>An alternative solution may be based on agent scheduler feature introduced in Grizzly-3. Agent scheduler feature includes infrastructure that supports API extension used for agent configuration, pluggable scheduling algorithms, health monitoring (good blog post on how the scheduler works <a href="http://www.mirantis.com/blog/a-new-agent-management-approach-in-quantum-for-openstack-grizzly/">http://www.mirantis.com/blog/a-new-agent-management-approach-in-quantum-for-openstack-grizzly/</a>)</div>
<div><br></div><div>Agent scheduler -based solution fits to all types of appliances: for type 1 appliances agent is located on the same host that provides service. For type 2 and 3 agent may be a single process per cloud, or as many as needed to have high availability. There may be one class of agent per service type / vendor or common agent extendable with service plugins. Agent may hold list of  appliances it configures, that list may be static or configurable via agent API (extension of agent scheduler API).</div>
<div><br></div><div>From code perspective the changes are:</div><div> 1. Introduce new type of agent (for lbaas we can base on reference implementation of lbaas-agent)</div><div> 2. Introduce new scheduling algorithm that takes into account capabilities of appliance, their load, etc.</div>
<div> 3. Introduce reporting protocol between agent and agent scheduler</div><div> 4. Introduce API for service agent just like it is done for l3-agent and dhcp-agent. This API may support operations for managing list of devices.</div>
<div><br></div><div>Any cons? </div><div><br></div><div>Thanks,</div><div>Ilya</div>