Browse Source

Add ceilometer-powervm spec dir and template

Add a specs directory structure for ceilometer-powervm and add in a
base spec template for creating new ceilometer-powervm specs

Change-Id: Ic07ebdf0dcdb26b4e6c76e1c45dc8bdb28d0d0ad
tags/3.0.0.0b1
adreznec 3 years ago
parent
commit
45809e9418
2 changed files with 256 additions and 0 deletions
  1. 1
    0
      specs/newton/template.rst
  2. 255
    0
      specs/template.rst

+ 1
- 0
specs/newton/template.rst View File

@@ -0,0 +1 @@
1
+../template.rst

+ 255
- 0
specs/template.rst View File

@@ -0,0 +1,255 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+==========================================
8
+Example Spec - The title of your blueprint
9
+==========================================
10
+
11
+Include the URL of your launchpad blueprint:
12
+
13
+https://blueprints.launchpad.net/ceilometer-powervm/+spec/example
14
+
15
+Introduction paragraph -- why are we doing anything? A single paragraph of
16
+prose that operators can understand. The title and this first paragraph
17
+should be used as the subject line and body of the commit message
18
+respectively.
19
+
20
+Some notes about using this template:
21
+
22
+* The aim of this document is first to define the problem we need to solve,
23
+  and second agree the overall approach to solve that problem.
24
+
25
+* You should aim to get your spec approved before writing your code.
26
+  While you are free to write prototypes and code before getting your spec
27
+  approved, its possible that the outcome of the spec review process leads
28
+  you towards a fundamentally different solution than you first envisaged.
29
+
30
+* Your spec should be in ReSTructured text, like this template.
31
+
32
+* Please wrap text at 79 columns.
33
+
34
+* The filename in the git repository should match the launchpad URL, for
35
+  example: https://blueprints.launchpad.net/ceilometer-powervm/+spec/awesome-thing
36
+  should be named awesome-thing.rst
37
+
38
+* Please do not delete any of the sections in this template.  If you have
39
+  nothing to say for a whole section, just write: None
40
+
41
+* For help with syntax, see http://sphinx-doc.org/rest.html
42
+
43
+* To test out your formatting, build the docs using tox and see the generated
44
+  HTML file in doc/build/html/specs/<path_of_your_file>
45
+
46
+* If you would like to provide a diagram with your spec, ascii diagrams are
47
+  required.  http://asciiflow.com/ is a very nice tool to assist with making
48
+  ascii diagrams.  The reason for this is that the tool used to review specs is
49
+  based purely on plain text.  Plain text will allow review to proceed without
50
+  having to look at additional files which can not be viewed in gerrit.  It
51
+  will also allow inline feedback on the diagram itself.
52
+
53
+
54
+Problem description
55
+===================
56
+
57
+A detailed description of the problem. What problem is this blueprint
58
+addressing?
59
+
60
+
61
+Use Cases
62
+---------
63
+
64
+What use cases does this address? What impact on actors does this change have?
65
+Ensure you are clear about the actors in each use case: Developer, End User,
66
+Deployer etc.
67
+
68
+
69
+Proposed change
70
+===============
71
+
72
+Here is where you cover the change you propose to make in detail. How do you
73
+propose to solve this problem?
74
+
75
+If this is one part of a larger effort make it clear where this piece ends. In
76
+other words, what's the scope of this effort?
77
+
78
+
79
+Alternatives
80
+------------
81
+
82
+What other ways could we do this thing? Why aren't we using those? This doesn't
83
+have to be a full literature review, but it should demonstrate that thought has
84
+been put into why the proposed solution is an appropriate one.
85
+
86
+
87
+Security impact
88
+---------------
89
+
90
+Describe any potential security impact on the system.  Some of the items to
91
+consider include:
92
+
93
+* Does this change touch sensitive data such as tokens, keys, or user data?
94
+
95
+* Does this change involve cryptography or hashing?
96
+
97
+* Does this change require the use of sudo or any elevated privileges?
98
+
99
+* Does this change involve using or parsing user-provided data? This could
100
+  be directly at the API level or indirectly such as changes to a cache layer.
101
+
102
+* Can this change enable a resource exhaustion attack, such as allowing a
103
+  single API interaction to consume significant server resources? Some examples
104
+  of this include launching subprocesses for each connection, or entity
105
+  expansion attacks in XML.
106
+
107
+For more detailed guidance, please see the OpenStack Security Guidelines as
108
+a reference (https://wiki.openstack.org/wiki/Security/Guidelines).  These
109
+guidelines are a work in progress and are designed to help you identify
110
+security best practices.  For further information, feel free to reach out
111
+to the OpenStack Security Group at openstack-security@lists.openstack.org.
112
+
113
+
114
+End user impact
115
+---------------
116
+
117
+How would the end user be impacted by this change? The "End User" is defined
118
+as the users of the deployed cloud?
119
+
120
+
121
+Performance Impact
122
+------------------
123
+
124
+Describe any potential performance impact on the system, for example
125
+how often will new code be called, and is there a major change to the calling
126
+pattern of existing code.
127
+
128
+Examples of things to consider here include:
129
+
130
+* A small change in a utility function or a commonly used decorator can have a
131
+  large impacts on performance.
132
+
133
+* Will the change include any locking, and if so what considerations are there
134
+  on holding the lock?
135
+
136
+
137
+Deployer impact
138
+---------------
139
+
140
+Discuss things that will affect how you deploy and configure OpenStack
141
+that have not already been mentioned, such as:
142
+
143
+* What config options are being added? Are the default values ones which will
144
+  work well in real deployments?
145
+
146
+* Is this a change that takes immediate effect after its merged, or is it
147
+  something that has to be explicitly enabled?
148
+
149
+* If this change is a new binary, how would it be deployed?
150
+
151
+* Please state anything that those doing continuous deployment, or those
152
+  upgrading from the previous release, need to be aware of. Also describe
153
+  any plans to deprecate configuration values or features.
154
+
155
+
156
+Developer impact
157
+----------------
158
+
159
+Discuss things that will affect other developers working on the driver or
160
+OpenStack in general.
161
+
162
+
163
+Implementation
164
+==============
165
+
166
+Assignee(s)
167
+-----------
168
+
169
+Who is leading the writing of the code? Or is this a blueprint where you're
170
+throwing it out there to see who picks it up?
171
+
172
+If more than one person is working on the implementation, please designate the
173
+primary author and contact.
174
+
175
+Primary assignee:
176
+  <launchpad-id or None>
177
+
178
+Other contributors:
179
+  <launchpad-id or None>
180
+
181
+Work Items
182
+----------
183
+
184
+Work items or tasks -- break the feature up into the things that need to be
185
+done to implement it. Those parts might end up being done by different people,
186
+but we're mostly trying to understand the timeline for implementation.
187
+
188
+
189
+Dependencies
190
+============
191
+
192
+* Include specific references to specs/blueprints in ceilometer-powervm, or
193
+  in other projects, that this one either depends on or is related to. For
194
+  example, a dependency on pypowervm changes should be documented here.
195
+
196
+* If this requires functionality of another project that is not currently used
197
+  by ceilometer-powervm document that fact.
198
+
199
+* Does this feature require any new library dependencies or code otherwise not
200
+  included in OpenStack? Or does it depend on a specific version of library?
201
+
202
+
203
+Testing
204
+=======
205
+
206
+Please discuss the important scenarios needed to test here, as well as
207
+specific edge cases we should be ensuring work correctly. For each
208
+scenario please specify if this requires specialized hardware, a full
209
+openstack environment, etc.
210
+
211
+Please discuss how the change will be tested. We especially want to know what
212
+functional tests will be added. It is assumed that unit test coverage will be
213
+added so that doesn't need to be mentioned explicitly.
214
+
215
+
216
+Documentation Impact
217
+====================
218
+
219
+Which audiences are affected most by this change, and which documentation
220
+titles should be updated because of this change? Don't repeat details
221
+discussed above, but reference them here in the context of documentation
222
+for multiple audiences.
223
+
224
+
225
+References
226
+==========
227
+
228
+Please add any useful references here. You are not required to have any
229
+reference. Moreover, this specification should still make sense when your
230
+references are unavailable. Examples of what you could include are:
231
+
232
+* Links to mailing list or IRC discussions
233
+
234
+* Links to notes from a summit session
235
+
236
+* Links to relevant research, if appropriate
237
+
238
+* Related specifications as appropriate
239
+
240
+* Anything else you feel it is worthwhile to refer to
241
+
242
+
243
+History
244
+=======
245
+
246
+Optional section intended to be used each time the spec is updated to describe
247
+new design.
248
+
249
+.. list-table:: Revisions
250
+   :header-rows: 1
251
+
252
+   * - Release Name
253
+     - Description
254
+   * - Mitaka
255
+     - Introduced

Loading…
Cancel
Save