https://blueprints.launchpad.net/openstack-cyborg/+spec/cyborg-agent
This spec proposes the responsibilities and initial design of the Cyborg Conductor.
Cyborg requires a conductor on the controller hosts to manage the cyborg system state and coalesce database operations.
Use of accelerators attached to virtual machine instances in OpenStack
Cyborg Conductor will reside on the control node and will be responsible for stateful actions taken by Cyborg. Acting as both a cache to the database and as a method of combining reads and writes to the database. All other Cyborg components will go through the conductor for database operations.
Having each Cyborg Agent instance hit the database on it’s own is a possible alternative, and it may even be feasible if the accelerator load monitoring rate is very low and the vast majority of operations are reads. But since we intend to store metadata about accelerator usage updated regularly this model probably will not scale well.
Using the conductor ‘properly’ will result in little or no per instance state and stateful operations moving through the conductor with the exception of some local caching where it can be garunteed to work well.
N/A
Negligible
N/A
Faster Cybrog operation and less database load.
Generally positive so long as we don’t overload the messaging bus trying to pass things to the Conductor to write out.
Conductor must be installed and configured on the controllers.
None for API users, internally heavy use of message passing will be required if we want to keep all system state in the controllers.
This component should be possible to fully test using unit tests and functional CI using the dummy driver.
Some configuration values tuning save out rate and other parameters on the controller will need to be documented for end users
Cyborg API Spec Cyborg Agent Spec
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.