Browse Source

Fix docs renderring, enforce instructions and template

This patch applies various documentation renderring fixes,
and enforces application of the instructions and the
template for the file names.

In addition to that it adds a requirement to add patches
related to the spec under specified Gerrit topics.

Change-Id: I36199cf78c30f2ee75c2d716b8919ceae2ab7c42
changes/74/643074/6
Roman Gorshunov 2 months ago
parent
commit
c5064ef2eb

+ 1
- 0
.gitignore View File

@@ -5,3 +5,4 @@
5 5
 /AUTHORS
6 6
 /ChangeLog
7 7
 .tox
8
+.vscode/

specs/approved/multi-linux-distros.rst → specs/approved/airship_multi_linux_distros.rst View File

@@ -5,18 +5,9 @@
5 5
   http://creativecommons.org/licenses/by/3.0/legalcode
6 6
 
7 7
 .. index::
8
-   single: template
9
-   single: creating specs
10
-
11
-.. note::
12
-
13
-  Blueprints are written using ReSTructured text.
14
-
15
-Add index directives to help others find your spec. E.g.::
16
-
17
-  .. index::
18
-     single: template
19
-     single: creating specs
8
+   single: Airship
9
+   single: multi-linux-distros
10
+   single: containers
20 11
 
21 12
 ===========================================
22 13
 Airship Multiple Linux Distribution Support
@@ -30,8 +21,9 @@ and other Linux distro's as new plugins.
30 21
 Links
31 22
 =====
32 23
 
33
-The work to author and implement this spec is tracked in Storyboard:
34
-https://storyboard.openstack.org/#!/story/2003699
24
+The work to author and implement this spec is tracked in Storyboard
25
+`2003699 <https://storyboard.openstack.org/#!/story/2003699>`_ and uses Gerrit
26
+topics ``airship_suse``, ``airship_rhel`` and similar.
35 27
 
36 28
 Problem description
37 29
 ===================

+ 109
- 95
specs/approved/data_config_generator.rst View File

@@ -150,34 +150,40 @@ Overall Architecture
150 150
 
151 151
   - Raw rack information from plugin:
152 152
 
153
+    ::
154
+
153 155
      vlan_network_data:
154 156
          oam:
155 157
              subnet: 12.0.0.64/26
156 158
              vlan: '1321'
157 159
 
160
+
158 161
   - Rules to define gateway, ip ranges from subnet:
159 162
 
163
+    ::
164
+
160 165
      rule_ip_alloc_offset:
161 166
          name: ip_alloc_offset
162 167
              ip_alloc_offset:
163 168
                  default: 10
164 169
                  gateway: 1
165 170
 
166
-   The above rule specify the ip offset to considered to define ip address for gateway, reserved
167
-   and static ip ranges from the subnet pool.
168
-   So ip range for 12.0.0.64/26 is : 12.0.0.65 ~ 12.0.0.126
169
-   The rule "ip_alloc_offset" now helps to define additional information as follows:
170 171
 
171
-     - gateway: 12.0.0.65 (the first offset as defined by the field 'gateway')
172
-     - reserved ip ranges: 12.0.0.65 ~ 12.0.0.76 (the range is defined by adding
173
-         "default" to start ip range)
174
-     - static ip ranges: 12.0.0.77 ~ 12.0.0.126 (it follows the rule that we need
175
-         to skip first 10 ip addresses as defined by "default")
172
+    The above rule specify the ip offset to considered to define ip address for gateway, reserved
173
+    and static ip ranges from the subnet pool.
174
+    So ip range for 12.0.0.64/26 is : 12.0.0.65 ~ 12.0.0.126
175
+    The rule "ip_alloc_offset" now helps to define additional information as follows:
176
+
177
+    - gateway: 12.0.0.65 (the first offset as defined by the field 'gateway')
178
+    - reserved ip ranges: 12.0.0.65 ~ 12.0.0.76 (the range is defined by adding
179
+      "default" to start ip range)
180
+    - static ip ranges: 12.0.0.77 ~ 12.0.0.126 (it follows the rule that we need
181
+      to skip first 10 ip addresses as defined by "default")
176 182
 
177 183
   - Intermediary YAML file information generated after applying the above rules
178 184
     to the raw rack information:
179 185
 
180
-::
186
+  ::
181 187
 
182 188
        network:
183 189
             vlan_network_data:
@@ -192,13 +198,13 @@ Overall Architecture
192 198
                 static_end: 12.0.0.126 ----+
193 199
                 vlan: '1321'
194 200
 
195
---
201
+  --
196 202
 
197
-   - J2 templates for specifying oam network data: It represents the format in
198
-     which the site manifests will be generated with values obtained from
199
-     Intermediary YAML
203
+  - J2 templates for specifying oam network data: It represents the format in
204
+    which the site manifests will be generated with values obtained from
205
+    Intermediary YAML
200 206
 
201
-::
207
+  ::
202 208
 
203 209
       ---
204 210
       schema: 'drydock/Network/v1'
@@ -230,12 +236,12 @@ Overall Architecture
230 236
             end: {{ data['network']['vlan_network_data']['oam']['static_end'] }}
231 237
       ...
232 238
 
233
---
239
+  --
234 240
 
235
-   - OAM Network information in site manifests after applying intermediary YAML to J2
236
-     templates.:
241
+  - OAM Network information in site manifests after applying intermediary YAML to J2
242
+    templates.:
237 243
 
238
-::
244
+  ::
239 245
 
240 246
       ---
241 247
       schema: 'drydock/Network/v1'
@@ -267,7 +273,7 @@ Overall Architecture
267 273
             end: 12.0.0.126
268 274
       ...
269 275
 
270
---
276
+  --
271 277
 
272 278
 Security impact
273 279
 ---------------
@@ -304,106 +310,114 @@ plugins.
304 310
 
305 311
   A. Excel Based Data Source.
306 312
 
307
-  - Gather the following input files:
308
-
309
-    1) Excel based site Engineering package. This file contains detail specification
310
-    covering IPMI, Public IPs, Private IPs, VLAN, Site Details, etc.
311
-
312
-    2) Excel Specification to aid parsing of the above Excel file. It contains
313
-    details about specific rows and columns in various sheet which contain the
314
-    necessary information to build site manifests.
315
-
316
-    3) Site specific configuration file containing additional configuration like
317
-    proxy, bgp information, interface names, etc.
313
+     - Gather the following input files:
318 314
 
319
-    4) Intermediary YAML file. In this cases Site Engineering Package and Excel
320
-    specification are not required.
315
+       1) Excel based site Engineering package. This file contains detail specification
316
+          covering IPMI, Public IPs, Private IPs, VLAN, Site Details, etc.
317
+       2) Excel Specification to aid parsing of the above Excel file. It contains
318
+          details about specific rows and columns in various sheet which contain the
319
+          necessary information to build site manifests.
320
+       3) Site specific configuration file containing additional configuration like
321
+          proxy, bgp information, interface names, etc.
322
+       4) Intermediary YAML file. In this cases Site Engineering Package and Excel
323
+          specification are not required.
321 324
 
322
-  B.  Remote Data Source
325
+  B. Remote Data Source
323 326
 
324
-  - Gather the following input information:
327
+     - Gather the following input information:
325 328
 
326
-    1) End point configuration file containing credentials to enable its access.
327
-    Each end-point type shall have their access governed by their respective plugins
328
-    and associated configuration file.
329
-
330
-    2) Site specific configuration file containing additional configuration like
331
-    proxy, bgp information, interface names, etc. These will be used if information
332
-    extracted from remote site is insufficient.
329
+       1) End point configuration file containing credentials to enable its access.
330
+          Each end-point type shall have their access governed by their respective plugins
331
+          and associated configuration file.
332
+       2) Site specific configuration file containing additional configuration like
333
+          proxy, bgp information, interface names, etc. These will be used if information
334
+          extracted from remote site is insufficient.
333 335
 
334 336
 * Program execution
335
-    1) CLI Options:
336
-
337
-      -g, --generate_intermediary  Dump intermediary file from passed Excel and
338
-                                   Excel spec.
339
-      -m, --generate_manifests     Generate manifests from the generated
340
-                                   intermediary file.
341
-      -x, --excel PATH             Path to engineering Excel file, to be passed
342
-                                   with generate_intermediary. The -s option is
343
-                                   mandatory with this option. Multiple engineering
344
-                                   files can be used. For example: -x file1.xls -x file2.xls
345
-      -s, --exel_spec PATH         Path to Excel spec, to be passed with
346
-                                   generate_intermediary. The -x option is
347
-                                   mandatory along with this option.
348
-      -i, --intermediary PATH      Path to intermediary file,to be passed
349
-                                   with generate_manifests. The -g and -x options
350
-                                   are not required with this option.
351
-      -d, --site_config PATH       Path to the site specific YAML file  [required]
352
-      -l, --loglevel INTEGER       Loglevel NOTSET:0 ,DEBUG:10,    INFO:20,
353
-                                   WARNING:30, ERROR:40, CRITICAL:50  [default:20]
354
-      -e, --end_point_config       File containing end-point configurations like user-name
355
-                                   password, certificates, URL, etc.
356
-      --help                       Show this message and exit.
357
-
358
-     2) Example:
359
-
360
-     2-1) Using Excel spec as input data source:
361
-
362
-      Generate Intermediary: spyglass -g -x <DesignSpec> -s <excel spec> -d <site-config>
363
-
364
-      Generate Manifest & Intermediary: spyglass -mg -x <DesignSpec> -s <excel spec> -d <site-config>
365
-
366
-      Generate Manifest with Intermediary: spyglass -m -i <intermediary>
367 337
 
368
-
369
-     2-1) Using external data source as input:
370
-
371
-      Generate Manifest and Intermediary : spyglass -m -g -e<end_point_config> -d <site-config>
372
-      Generate Manifest : spyglass -m  -e<end_point_config> -d <site-config>
373
-
374
-      Note: The end_point_config shall include attributes of the external data source that are
375
-      necessary for its access. Each external data source type shall have its own plugin to configure
376
-      its corresponding credentials.
338
+  1. CLI Options:
339
+
340
+     +-----------------------------+-----------------------------------------------------------+
341
+     | -g, --generate_intermediary | Dump intermediary file from passed Excel and              |
342
+     |                             | Excel spec.                                               |
343
+     +-----------------------------+-----------------------------------------------------------+
344
+     | -m, --generate_manifests    | Generate manifests from the generated                     |
345
+     |                             | intermediary file.                                        |
346
+     +-----------------------------+-----------------------------------------------------------+
347
+     | -x, --excel PATH            | Path to engineering Excel file, to be passed              |
348
+     |                             | with generate_intermediary. The -s option is              |
349
+     |                             | mandatory with this option. Multiple engineering          |
350
+     |                             | files can be used. For example: -x file1.xls -x file2.xls |
351
+     +-----------------------------+-----------------------------------------------------------+
352
+     | -s, --exel_spec PATH        | Path to Excel spec, to be passed with                     |
353
+     |                             | generate_intermediary. The -x option is                   |
354
+     |                             | mandatory along with this option.                         |
355
+     +-----------------------------+-----------------------------------------------------------+
356
+     | -i, --intermediary PATH     | Path to intermediary file,to be passed                    |
357
+     |                             | with generate_manifests. The -g and -x options            |
358
+     |                             | are not required with this option.                        |
359
+     +-----------------------------+-----------------------------------------------------------+
360
+     | -d, --site_config PATH      | Path to the site specific YAML file  [required]           |
361
+     +-----------------------------+-----------------------------------------------------------+
362
+     | -l, --loglevel INTEGER      | Loglevel NOTSET:0 ,DEBUG:10,    INFO:20,                  |
363
+     |                             | WARNING:30, ERROR:40, CRITICAL:50  [default:20]           |
364
+     +-----------------------------+-----------------------------------------------------------+
365
+     | -e, --end_point_config      | File containing end-point configurations like user-name   |
366
+     |                             | password, certificates, URL, etc.                         |
367
+     +-----------------------------+-----------------------------------------------------------+
368
+     | --help                      | Show this message and exit.                               |
369
+     +-----------------------------+-----------------------------------------------------------+
370
+
371
+  2. Example:
372
+
373
+    1) Using Excel spec as input data source:
374
+
375
+       Generate Intermediary: ``spyglass -g -x <DesignSpec> -s <excel spec> -d <site-config>``
376
+
377
+       Generate Manifest & Intermediary: ``spyglass -mg -x <DesignSpec> -s <excel spec> -d <site-config>``
378
+
379
+       Generate Manifest with Intermediary: ``spyglass -m -i <intermediary>``
380
+
381
+    2) Using external data source as input:
382
+
383
+       Generate Manifest and Intermediary: ``spyglass -m -g -e<end_point_config> -d <site-config>``
384
+
385
+       Generate Manifest: ``spyglass -m  -e<end_point_config> -d <site-config>``
386
+
387
+       .. note::
388
+
389
+         The end_point_config shall include attributes of the external data source that are
390
+         necessary for its access. Each external data source type shall have its own plugin to configure
391
+         its corresponding credentials.
377 392
 
378 393
 * Program output:
394
+
379 395
     a) Site Manifests: As an initial release, the program shall output manifest files for
380 396
        "airship-seaworthy" site. For example: baremetal, deployment, networks, pki, etc.
381
-       Reference:https://github.com/openstack/airship-treasuremap/tree/master/site/airship-seaworthy
397
+       Reference: https://github.com/openstack/airship-treasuremap/tree/master/site/airship-seaworthy
382 398
     b) Intermediary YAML: Containing aggregated site information generated from data sources that is
383 399
        used to generate the above site manifests.
384 400
 
385 401
 Future Work
386 402
 ============
387
-1) Schema based manifest generation instead of Jinja2 templates. It shall
388
-be possible to cleanly transition to this schema based generation keeping a unique
389
-mapping between schema and generated manifests. Currently this is managed by
390
-considering a mapping of j2 templates with schemas and site type.
391
-
392
-2) UI editor for intermediary YAML
403
+1. Schema based manifest generation instead of Jinja2 templates. It shall
404
+   be possible to cleanly transition to this schema based generation keeping a unique
405
+   mapping between schema and generated manifests. Currently this is managed by
406
+   considering a mapping of j2 templates with schemas and site type.
407
+2. UI editor for intermediary YAML
393 408
 
394 409
 
395 410
 Alternatives
396 411
 ============
397
-1) Schema based manifest generation instead of Jinja2 templates.
398
-2) Develop the data source plugins as an extension to Pegleg.
412
+1. Schema based manifest generation instead of Jinja2 templates.
413
+2. Develop the data source plugins as an extension to Pegleg.
399 414
 
400 415
 Dependencies
401 416
 ============
402
-1) Availability of a repository to store Jinja2 templates.
403
-2) Availability of a repository to store generated manifests.
417
+1. Availability of a repository to store Jinja2 templates.
418
+2. Availability of a repository to store generated manifests.
404 419
 
405 420
 References
406 421
 ==========
407 422
 
408 423
 None
409
-

+ 2
- 0
specs/approved/divingbell_ansible_framework.rst View File

@@ -60,6 +60,7 @@ A separate directory structure needs to be created for adding the playbooks.
60 60
 Each Divingbell config can be a separate role within the playbook structure.
61 61
 
62 62
 ::
63
+
63 64
     - playbooks/
64 65
         - roles/
65 66
              - systcl/
@@ -83,6 +84,7 @@ With Divingbell DaemonSet running on each host mounted at ``hostPath``,
83 84
 ``hosts`` should be defined as given below within the ``master.yml``.
84 85
 
85 86
 ::
87
+
86 88
     hosts: all
87 89
     connection: chroot
88 90
 

+ 2
- 6
specs/approved/drydock_support_bios_configuration.rst View File

@@ -193,14 +193,10 @@ Work Items
193 193
 ----------
194 194
 
195 195
 - Update Hardware profile schema to support new attribute bios_setting
196
-
197 196
 - Update Hardware profile objects
198
-
199 197
 - Update Orchestrator action PrepareNodes to call OOB driver for BIOS
200 198
   configuration
201
-
202 199
 - Update Redfish OOB driver to support new action ConfigBIOS
203
-
204 200
 - Add unit test cases
205 201
 
206 202
 Assignee(s):
@@ -215,8 +211,8 @@ Other contributors:
215 211
 Dependencies
216 212
 ============
217 213
 
218
-This spec depends on ``Introduce Redfish based OOB Driver for Drydock``
219
-https://storyboard.openstack.org/#!/story/2003007
214
+This spec depends on `Introduce Redfish based OOB Driver for Drydock <https://storyboard.openstack.org/#!/story/2003007>`_
215
+story.
220 216
 
221 217
 References
222 218
 ==========

+ 1
- 1
specs/approved/k8s_external_facing_api.rst View File

@@ -45,7 +45,7 @@ Impacted components
45 45
 The following Airship components would be impacted by this solution:
46 46
 
47 47
 #. Promenade - Maintenance of the chart for external facing Kubernetes API
48
-servers
48
+   servers
49 49
 
50 50
 Proposed change
51 51
 ===============

specs/approved/pegleg-secrets.rst → specs/approved/pegleg_secrets.rst View File

@@ -5,8 +5,8 @@
5 5
   http://creativecommons.org/licenses/by/3.0/legalcode
6 6
 
7 7
 .. index::
8
-   single: template
9
-   single: creating specs
8
+   single: Pegleg
9
+   single: Security
10 10
 
11 11
 =======================================
12 12
 Pegleg Secret Generation and Encryption

+ 41
- 52
specs/approved/workflow_node-teardown.rst View File

@@ -150,21 +150,26 @@ details:
150 150
 #. Drain the Kubernetes node.
151 151
 #. Clear the Kubernetes labels on the node.
152 152
 #. Remove etcd nodes from their clusters (if impacted).
153
+
153 154
    - if the node being decommissioned contains etcd nodes, Promenade will
154
-   attempt to gracefully have those nodes leave the etcd cluster.
155
+     attempt to gracefully have those nodes leave the etcd cluster.
156
+
155 157
 #. Ensure that etcd cluster(s) are in a stable state.
158
+
156 159
    - Polls for status every 30 seconds up to the etcd-ready-timeout, or the
157
-   cluster meets the defined minimum functionality for the site.
160
+     cluster meets the defined minimum functionality for the site.
158 161
    - A new document: promenade/EtcdClusters/v1 that will specify details about
159
-   the etcd clusters deployed in the site, including: identifiers,
160
-   credentials, and thresholds for minimum functionality.
162
+     the etcd clusters deployed in the site, including: identifiers,
163
+     credentials, and thresholds for minimum functionality.
161 164
    - This process should ignore the node being torn down from any calculation
162
-   of health
165
+     of health
166
+
163 167
 #. Shutdown the kubelet.
168
+
164 169
    - If this is not possible because the node is in a state of disarray such
165
-   that it cannot schedule the daemonset to run, this step may fail, but
166
-   should not hold up the process, as the Drydock dismantling of the node
167
-   will shut the kubelet down.
170
+     that it cannot schedule the daemonset to run, this step may fail, but
171
+     should not hold up the process, as the Drydock dismantling of the node
172
+     will shut the kubelet down.
168 173
 
169 174
 Responses
170 175
 ~~~~~~~~~
@@ -173,11 +178,9 @@ All responses will be form of the Airship Status response.
173 178
 -  Success: Code: 200, reason: Success
174 179
 
175 180
    Indicates that all steps are successful.
176
-
177 181
 -  Failure: Code: 404, reason: NotFound
178 182
 
179 183
    Indicates that the target node is not discoverable by Promenade.
180
-
181 184
 -  Failure: Code: 500, reason: DisassociateStepFailure
182 185
 
183 186
    The details section should detail the successes and failures further. Any
@@ -223,16 +226,13 @@ All responses will be form of the Airship Status response.
223 226
 
224 227
    Indicates that the drain node has successfully concluded, and that no pods
225 228
    are currently running
226
-
227 229
 -  Failure: Status response, code: 400, reason: BadRequest
228 230
 
229 231
    A request was made with parameters that cannot work - e.g. grace-period is
230 232
    set to a value larger than the timeout value.
231
-
232 233
 -  Failure: Status response, code: 404, reason: NotFound
233 234
 
234 235
    The specified node is not discoverable by Promenade
235
-
236 236
 -  Failure: Status response, code: 500, reason: DrainNodeError
237 237
 
238 238
    There was a processing exception raised while trying to drain a node. The
@@ -263,11 +263,9 @@ All responses will be form of the Airship Status response.
263 263
 -  Success: Code: 200, reason: Success
264 264
 
265 265
    All labels have been removed from the specified Kubernetes node.
266
-
267 266
 -  Failure: Code: 404, reason: NotFound
268 267
 
269 268
    The specified node is not discoverable by Promenade
270
-
271 269
 -  Failure: Code: 500, reason: ClearLabelsError
272 270
 
273 271
    There was a failure to clear labels that prevented completion. The details
@@ -298,11 +296,9 @@ All responses will be form of the Airship Status response.
298 296
 -  Success: Code: 200, reason: Success
299 297
 
300 298
    All etcd nodes have been removed from the specified node.
301
-
302 299
 -  Failure: Code: 404, reason: NotFound
303 300
 
304 301
    The specified node is not discoverable by Promenade
305
-
306 302
 -  Failure: Code: 500, reason: RemoveEtcdError
307 303
 
308 304
    There was a failure to remove etcd from the target node that prevented
@@ -315,7 +311,7 @@ Promenade Check etcd
315 311
 ~~~~~~~~~~~~~~~~~~~~
316 312
 Retrieves the current interpreted state of etcd.
317 313
 
318
-GET /etcd-cluster-health-statuses?design_ref={the design ref}
314
+  GET /etcd-cluster-health-statuses?design_ref={the design ref}
319 315
 
320 316
 Where the design_ref parameter is required for appropriate operation, and is in
321 317
 the same format as used for the join-scripts API.
@@ -334,42 +330,40 @@ All responses will be form of the Airship Status response.
334 330
    The status of each etcd in the site will be returned in the details section.
335 331
    Valid values for status are: Healthy, Unhealthy
336 332
 
337
-https://github.com/openstack/airship-in-a-bottle/blob/master/doc/source/api-conventions.rst#status-responses
338
-
339
-.. code:: json
340
-
341
-  { "...": "... standard status response ...",
342
-    "details": {
343
-      "errorCount": {{n}},
344
-      "messageList": [
345
-        { "message": "Healthy",
346
-          "error": false,
347
-          "kind": "HealthMessage",
348
-          "name": "{{the name of the etcd service}}"
349
-        },
350
-        { "message": "Unhealthy"
351
-          "error": false,
352
-          "kind": "HealthMessage",
353
-          "name": "{{the name of the etcd service}}"
354
-        },
355
-        { "message": "Unable to access Etcd"
356
-          "error": true,
357
-          "kind": "HealthMessage",
358
-          "name": "{{the name of the etcd service}}"
359
-        }
360
-      ]
361
-    }
362
-    ...
363
-  }
333
+   https://github.com/openstack/airship-in-a-bottle/blob/master/doc/source/api-conventions.rst#status-responses
334
+
335
+   .. code:: json
336
+
337
+     { "...": "... standard status response ...",
338
+       "details": {
339
+         "errorCount": {{n}},
340
+         "messageList": [
341
+           { "message": "Healthy",
342
+             "error": false,
343
+             "kind": "HealthMessage",
344
+             "name": "{{the name of the etcd service}}"
345
+           },
346
+           { "message": "Unhealthy"
347
+             "error": false,
348
+             "kind": "HealthMessage",
349
+             "name": "{{the name of the etcd service}}"
350
+           },
351
+           { "message": "Unable to access Etcd"
352
+             "error": true,
353
+             "kind": "HealthMessage",
354
+             "name": "{{the name of the etcd service}}"
355
+           }
356
+         ]
357
+       }
358
+       ...
359
+     }
364 360
 
365 361
 -  Failure: Code: 400, reason: MissingDesignRef
366 362
 
367 363
    Returned if the design_ref parameter is not specified
368
-
369 364
 -  Failure: Code: 404, reason: NotFound
370 365
 
371 366
    Returned if the specified etcd could not be located
372
-
373 367
 -  Failure: Code: 500, reason: EtcdNotAccessible
374 368
 
375 369
    Returned if the specified etcd responded with an invalid health response
@@ -400,11 +394,9 @@ All responses will be form of the Airship Status response.
400 394
 -  Success: Code: 200, reason: Success
401 395
 
402 396
    The kubelet has been successfully shutdown
403
-
404 397
 -  Failure: Code: 404, reason: NotFound
405 398
 
406 399
    The specified node is not discoverable by Promenade
407
-
408 400
 -  Failure: Code: 500, reason: ShutdownKubeletError
409 401
 
410 402
    The specified node's kubelet fails to shutdown. The details section of the
@@ -433,17 +425,14 @@ All responses will be form of the Airship Status response.
433 425
 -  Success: Code: 200, reason: Success
434 426
 
435 427
    The specified node has been removed from the Kubernetes cluster.
436
-
437 428
 -  Failure: Code: 404, reason: NotFound
438 429
 
439 430
    The specified node is not discoverable by Promenade
440
-
441 431
 -  Failure: Code: 409, reason: Conflict
442 432
 
443 433
    The specified node cannot be deleted due to checks that the node is
444 434
    drained/cordoned and has no labels (other than possibly
445 435
    `promenade-decomission: enabled`).
446
-
447 436
 -  Failure: Code: 500, reason: DeleteNodeError
448 437
 
449 438
    The specified node cannot be removed from the cluster due to an error from

+ 38
- 32
specs/instructions.rst View File

@@ -20,6 +20,12 @@ Instructions
20 20
   a short explanation.
21 21
 - New specs for review should be placed in the ``approved`` subfolder, where
22 22
   they will undergo review and approval in Gerrit_.
23
+- Test if the spec file renders correctly in a web-browser by running
24
+  ``make docs`` command and opening ``doc/build/html/index.html`` in a
25
+  web-browser. Ubuntu needs the following packages to be installed::
26
+
27
+    apt-get install -y make tox gcc python3-dev
28
+
23 29
 - Specs that have finished implementation should be moved to the
24 30
   ``implemented`` subfolder.
25 31
 
@@ -50,38 +56,38 @@ Use the following guidelines to determine the category to use for a document:
50 56
 1) For new functionality and features, the best choice for a category is to
51 57
    match a functional duty of Airship.
52 58
 
53
-site-definition
54
-  Parts of the platform that support the definition of a site, including
55
-  management of the yaml definitions, document authoring and translation, and
56
-  the collation of source documents.
57
-
58
-genesis
59
-  Used for the steps related to preparation and deployment of the genesis node
60
-  of an Airship deployment.
61
-
62
-baremetal
63
-  Those changes to Airflow that provide for the lifecycle of bare metal
64
-  components of the system - provisioning, maintenance, and teardown. This
65
-  includes booting, hardware and network configuration, operating system, and
66
-  other host-level management
67
-
68
-k8s
69
-  For functionality that is about interfacing with Kubernetes directly, other
70
-  than the initial setup that is done during genesis.
71
-
72
-software
73
-  Functionality that is related to the deployment or redeployment of workload
74
-  onto the Kubernetes cluster.
75
-
76
-workflow
77
-  Changes to existing workflows to provide new functionality and creation of
78
-  new workflows that span multiple other areas (e.g. baremetal, k8s, software),
79
-  or those changes that are new arrangements of existing functionality in one
80
-  or more of those other areas.
81
-
82
-administration
83
-  Security, logging, auditing, monitoring, and those things related to site
84
-  administrative functions of the Airship platform.
59
+   site-definition
60
+     Parts of the platform that support the definition of a site, including
61
+     management of the yaml definitions, document authoring and translation, and
62
+     the collation of source documents.
63
+
64
+   genesis
65
+     Used for the steps related to preparation and deployment of the genesis node
66
+     of an Airship deployment.
67
+
68
+   baremetal
69
+     Those changes to Airflow that provide for the lifecycle of bare metal
70
+     components of the system - provisioning, maintenance, and teardown. This
71
+     includes booting, hardware and network configuration, operating system, and
72
+     other host-level management
73
+
74
+   k8s
75
+     For functionality that is about interfacing with Kubernetes directly, other
76
+     than the initial setup that is done during genesis.
77
+
78
+   software
79
+     Functionality that is related to the deployment or redeployment of workload
80
+     onto the Kubernetes cluster.
81
+
82
+   workflow
83
+     Changes to existing workflows to provide new functionality and creation of
84
+     new workflows that span multiple other areas (e.g. baremetal, k8s, software),
85
+     or those changes that are new arrangements of existing functionality in one
86
+     or more of those other areas.
87
+
88
+   administration
89
+     Security, logging, auditing, monitoring, and those things related to site
90
+     administrative functions of the Airship platform.
85 91
 
86 92
 2) For specs that are not feature focused, the component of the system may
87 93
    be the best choice for a category, e.g. ``shipyard``, ``armada`` etc...

+ 4
- 4
specs/template.rst View File

@@ -12,7 +12,7 @@
12 12
 
13 13
   Blueprints are written using ReSTructured text.
14 14
 
15
-Add index directives to help others find your spec. E.g.::
15
+Add *index* directives to help others find your spec by keywords. E.g.::
16 16
 
17 17
   .. index::
18 18
      single: template
@@ -27,9 +27,9 @@ Introduction paragraph -- What is this blueprint about?
27 27
 Links
28 28
 =====
29 29
 
30
-Include pertinent links to where the work is being tracked (e.g. Storyboard),
31
-as well as any other foundational information that may lend clarity to this
32
-blueprint
30
+Include pertinent links to where the work is being tracked (e.g. Storyboard ID
31
+and Gerrit topics), as well as any other foundational information that may lend
32
+clarity to this blueprint
33 33
 
34 34
 Problem description
35 35
 ===================

Loading…
Cancel
Save