blob: a1e8ffcbfeb889380cdd091f4ace4d5c0dc400ff (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
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
|
