1 files changed, 142 insertions, 0 deletions
diff --git a/cyborg_enhancement/mitaka_version/cyborg/doc/source/devdoc/specs/pike/approved/cyborg-conductor.rst b/cyborg_enhancement/mitaka_version/cyborg/doc/source/devdoc/specs/pike/approved/cyborg-conductor.rst
new file mode 100644
index 0000000..a1e8ffc
--- /dev/null
+++ b/cyborg_enhancement/mitaka_version/cyborg/doc/source/devdoc/specs/pike/approved/cyborg-conductor.rst
@@ -0,0 +1,142 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+==========================================
+     Cyborg Conductor Proposal
+==========================================
+
+https://blueprints.launchpad.net/openstack-cyborg/+spec/cyborg-agent
+
+This spec proposes the responsibilities and initial design of the
+Cyborg Conductor.
+
+Problem description
+===================
+
+Cyborg requires a conductor on the controller hosts to manage the cyborg
+system state and coalesce database operations.
+
+Use Cases
+---------
+
+Use of accelerators attached to virtual machine instances in OpenStack
+
+Proposed change
+===============
+
+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.
+
+Alternatives
+------------
+
+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.
+
+Data model impact
+-----------------
+
+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.
+
+REST API impact
+---------------
+
+N/A
+
+Security impact
+---------------
+
+Negligible
+
+Notifications impact
+--------------------
+
+N/A
+
+Other end user impact
+---------------------
+
+Faster Cybrog operation and less database load.
+
+Performance Impact
+------------------
+
+Generally positive so long as we don't overload the messaging bus trying
+to pass things to the Conductor to write out.
+
+Other deployer impact
+---------------------
+
+Conductor must be installed and configured on the controllers.
+
+
+Developer impact
+----------------
+
+None for API users, internally heavy use of message passing will
+be required if we want to keep all system state in the controllers.
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  jkilpatr
+
+Other contributors:
+  None
+
+Work Items
+----------
+
+* Implementation
+* Integration with API and Agent
+
+Dependencies
+============
+
+* Cyborg API spec
+* Cyborg Agent spec
+
+Testing
+=======
+
+This component should be possible to fully test using unit tests and functional
+CI using the dummy driver.
+
+Documentation Impact
+====================
+
+Some configuration values tuning save out rate and other parameters on the controller
+will need to be documented for end users
+
+References
+==========
+
+Cyborg API Spec
+Cyborg Agent Spec
+
+History
+=======
+
+
+.. list-table:: Revisions
+   :header-rows: 1
+
+   * - Release
+     - Description
+   * - Pike
+     - Introduced