[openstack-dev] [Networking] [*aaS] Agent scheduler as Device inventory

Ilya Shakhat ishakhat at mirantis.com
Thu May 16 16:47:20 UTC 2013


Hi,

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:
 1) on-host process - ex. haproxy as process on network controller or
dedicated node with running haproxy
 2) VM running on compute node
 3) physical appliance

The current proposal is to introduce 'device inventory' module (
https://blueprints.launchpad.net/quantum/+spec/device-inventory-management).
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.

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
http://www.mirantis.com/blog/a-new-agent-management-approach-in-quantum-for-openstack-grizzly/
)

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).

>From code perspective the changes are:
 1. Introduce new type of agent (for lbaas we can base on reference
implementation of lbaas-agent)
 2. Introduce new scheduling algorithm that takes into account capabilities
of appliance, their load, etc.
 3. Introduce reporting protocol between agent and agent scheduler
 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.

Any cons?

Thanks,
Ilya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/f83682e9/attachment.html>


More information about the OpenStack-dev mailing list