Merge "Fix Yamllint Violations"

2 files changed, 130 insertions, 120 deletions

diff --git a/scenarios/examples/sdf-fdio-example.yaml b/scenarios/examples/sdf-fdio-example.yaml
index cbac4fb..7ea0ba8 100644
--- a/scenarios/examples/sdf-fdio-example.yaml
+++ b/scenarios/examples/sdf-fdio-example.yaml
@@ -1,3 +1,4 @@
+---
 ##############################################################################
 # Copyright (c) 2017 Huawei others.
 # ulrich.kleber@huawei.com
@@ -21,7 +22,7 @@ scenario-metadata:
   title: fdio odl basic for devops
   generic-scenario: false
   version: 1.0.0
-  creation-date:  2017-03-16
+  creation-date: 2017-03-16
   # This scenario introduces fd.io with odl and a basic feature set.
   # It is derived from parent odl_l2 nofeature. In a next step, odl_l2 and
   # old_l3 functionality shall be merged and provide sfc as well as other
@@ -48,7 +49,7 @@ components:
         - vpp
   - storage:
       component-type: ceph
-      #$$$$ Should we add num-replicas 3 here?
+      # $$$$ Should we add num-replicas 3 here?
 
   - cloud-controller:
       type: openstack
@@ -103,7 +104,7 @@ deployment-options:
         nodes:
           - name: host1
             roles:
-              - openstack-controller # need to add fd.io?
+              - openstack-controller  # need to add fd.io?
               - odl
           - name: host2
             roles:
@@ -120,11 +121,11 @@ deployment-options:
             roles:
               - openstack-compute
   deployment-tools:
-    - apex:
-         cpu: intel
-         pod: baremetal
-         availability: ha
     # fuel support shall be added soon
+    - apex:
+        cpu: intel
+        pod: baremetal
+        availability: ha
 ##############################################################################
 
 ##############################################################################
diff --git a/scenarios/templates/sdf-template.yaml b/scenarios/templates/sdf-template.yaml
index 81265e8..2f0121b 100644
--- a/scenarios/templates/sdf-template.yaml
+++ b/scenarios/templates/sdf-template.yaml
@@ -1,3 +1,4 @@
+---
 ##############################################################################
 # Copyright (c) 2017 Huawei and others.
 # ulrich.kleber@huawei.com
@@ -19,45 +20,47 @@
 #
 # metadata (owner, history, description)
 # list of components (names, versions, submodules)
-# deployment options (HA/NOHA, hardware&virtualization, installers, configurations)
+# deployment options (HA/NOHA, hardware&virtualization, installers,
+#                     configurations)
 # other prerequisites (e.g. memory requirement more than pharos spec)
 #
 # More details can be found in the scenario lifecycle document.
 ##############################################################################
 
 ##############################################################################
-# scenario meta-data    # Metadata describing this sdf.yaml file and the scenario
-                        # history and purpose.
+# scenario meta-data    # Metadata describing this sdf.yaml file and the
+#                         scenario history and purpose.
 scenario-metadata:
   name: SDF-Template            # mandatory
-# This is a free name.
-# For Generic scenarios, the main distiguishing components can be included in
-# the name. The name will be approved by TSC when the generic scenario is
-# established. Examples: OS-ODL-OVSNSH, OS-ONOS, OS-ODL-FDIO,
-# OS-OVSBasic, OS-FDIOBasic, ... 
-# For specific scenarios, the name should characterize the main
-# feature that is implemented here. Examples: Bgpvpn, Netvirt-gbp-vpp,
-# Dpdk-bar, Onos-sfc, ...
-# Final rules for naming will be set by the lifecycle document and TSC approval.
+  # This is a free name.
+  # For Generic scenarios, the main distiguishing components can be included in
+  # the name. The name will be approved by TSC when the generic scenario is
+  # established. Examples: OS-ODL-OVSNSH, OS-ONOS, OS-ODL-FDIO,
+  # OS-OVSBasic, OS-FDIOBasic, ...
+  # For specific scenarios, the name should characterize the main
+  # feature that is implemented here. Examples: Bgpvpn, Netvirt-gbp-vpp,
+  # Dpdk-bar, Onos-sfc, ...
+  # Final rules for naming will be set by the lifecycle document and TSC
+  # approval.
   title: "SDF template"         # mandatory
-# descriptive text title maximum 10-12 words telling the main purpose
+  # descriptive text title maximum 10-12 words telling the main purpose
   generic-scenario: false       # optional, default = false
   version: 1.0.6                # mandatory
-# version number of the sdf, three digits separated with dots
-  creation-date:  2017-05-09    # mandatory
-# creation of this sdf file version
+  # version number of the sdf, three digits separated with dots
+  creation-date: 2017-05-09    # mandatory
+  # creation of this sdf file version
   # Please add a clear description of the purpose of the scenario, including
   # the main benefits and major features (mandatory).
   # If applicable, the parent scenario should be mentioned.
   opnfv-release: euphrates      # mandatory
-# the first opnfv release, the scenario was introduced
+  # the first opnfv release, the scenario was introduced
   opnfv-version:
     - begins: 5.1.0             # mandatory
-# the first opnfv version, the scenario was released with
+    # the first opnfv version, the scenario was released with
     - ends: 7.3.0               # optional
-# the last opnfv version that supports this scenario. Typically the features
-# of the scenario should have been merged to generic scenarios then
-  owner: Ulrich Kleber, ulrich.kleber@huawei.com # mandatory
+    # the last opnfv version that supports this scenario. Typically the features
+    # of the scenario should have been merged to generic scenarios then
+  owner: Ulrich Kleber, ulrich.kleber@huawei.com  # mandatory
 # author of this file and thus owner of the scenario
 # Add additional contact persons e.g. from installers or major components
 
@@ -67,67 +70,72 @@ scenario-metadata:
 # components
 # All components/submodules/features in the list shall be deployed
 components:                     # mandatory section
-# In this section all components are listed together with their version.
-# For some components in addtion submodules or optional features can be listed.
+  # In this section all components are listed together with their version.
+  # For some components in addtion submodules or optional features can
+  # be listed.
   - sdn-controller:             # optional, default = no sdn controller
-# most important categories here are: sdn-controller, cloud-controller,
-# storage, virtual-switching, dataplane, nfvo, vnfm, but new categories
-# can be introduced any time.
-# Every component to be deployed should be listed with such a section.
-# If the component has submodules or optional features, they also need
-# to be listed.
-      type: opendaylight        # mandatory, other options e.g.onos, ocl, ovn
-      release: boron            # either release or version or both must be given
-# upstream version, human readable release name
-      version: 5.0.1
-# exact semantic version including patch level
-# Normally installers will not be able to pick exact semantic versions, but
-# if the scenario requires specific versions, this can be checked offline.
-# Following syntax variants can be allowed as well:
-#     version: 5.*.*
-#     version: ">5.0.3"
-      features:                 # optional
-# additional feature configurations as recognized by the installers.
-        - odl_l2
-        - sfc
-        - bgpvpn
+    # most important categories here are: sdn-controller, cloud-controller,
+    # storage, virtual-switching, dataplane, nfvo, vnfm, but new categories
+    # can be introduced any time.
+    # Every component to be deployed should be listed with such a section.
+    # If the component has submodules or optional features, they also need
+    # to be listed.
+    type: opendaylight        # mandatory, other options e.g.onos, ocl, ovn
+    release: boron            # either release or version or both must be given
+    # upstream version, human readable release name
+    version: 5.0.1
+    # exact semantic version including patch level
+    # Normally installers will not be able to pick exact semantic versions, but
+    # if the scenario requires specific versions, this can be checked offline.
+    # Following syntax variants can be allowed as well:
+    #     version: 5.*.*
+    #     version: ">5.0.3"
+    features:                 # optional
+      # additional feature configurations as recognized by the installers.
+      - odl_l2
+      - sfc
+      - bgpvpn
 
-  - storage:                    # optional
+  - storage:                 # optional
       type: ceph
 
-  - cloud-controller:           # seems to me mandatory
-      type: openstack           # other option could be kubernetes
-      release: ocata            # either release or version or both must be given
+  - cloud-controller:        # seems to me mandatory
+      type: openstack        # other option could be kubernetes
+      release: ocata         # either release or version or both must be given
       version: 15.0.0
-# An OPNFV version can go only with one openstack version. Typically installers
-# cannot pick different openstack version, but this can be checked offline.
+      # An OPNFV version can go only with one openstack version.
+      # Typically installers cannot pick different openstack version,
+      # but this can be checked offline.
       modules:                  # optional
-# Installers have a basic set of modules that are deployed by default. Those
-# can be listed optional. Scenario owners can list additional optional modules
-# with their name as on https://wiki.openstack.org/software/project-navigator,
-# but with lower case and dashes, Examples: tacker, kuryr, horizon, vitrage,
-# chef-openstack, openstack-charms, etc.
-# Independent of big tent, modules can be used if installers support their deployment.
+        # Installers have a basic set of modules that are deployed by
+        # default. Those can be listed optional. Scenario owners can
+        # list additional optional modules with their name as on
+        # https://wiki.openstack.org/software/project-navigator, but
+        # with lower case and dashes, Examples: tacker, kuryr, horizon,
+        # vitrage, chef-openstack, openstack-charms, etc.
+        # Independent of big tent, modules can be used if installers
+        # support their deployment.
         - nova
         - cinder
         - horizon
         - glance
         - heat
         - neutron:
-            features:           # In some cases features need to be listed specifically
-              - bgpvpn          # listing service plugins as neutron features makes
-# it easier for installers, they don't need to take this information from the features
-# field in the sdn-controller.
+            features:   # In some cases features need to be listed specifically
+              - bgpvpn  # listing service plugins as neutron features makes
+        # it easier for installers, they don't need to take this
+        # information from the features field in the sdn-controller.
         - aodh
         - tacker
         - congress
 
-  - virtual-switching:          # optional
-# showing with this example how to include a separate configuration file for this
+  - virtual-switching:      # optional
+      # showing with this example how to include a separate
+      # configuration file for this
       type: ovs
-      release: xx               # either release or version or both must be given
+      release: xx           # either release or version or both must be given
       version: 2.6.1
-      features:                 # optional
+      features:             # optional
         - vsperf:
             file: scenarios/ovs-config.yaml
 # this file then should contain additional configurations to use like
@@ -136,8 +144,8 @@ components:                     # mandatory section
 # Please note, the template cannot show all possible options here. There will be
 # more in an additional document.
 # Correct usage of the keywords/options will be enforced by a schema.
-# Also note that some component related deployment information will be in the options
-# section.
+# Also note that some component related deployment information will be
+# in the options section.
 ##############################################################################
 
 ##############################################################################
@@ -151,35 +159,36 @@ deployment-options:             # mandatory
       features:                 # optional
         - dpdk
         - other
-#$$$$ Discussion open whether we need features here after adding them in roles section
+    # $$$$ Discussion open whether we need features here after adding
+    # them in roles section
     - baremetal:
       architecture: arm64
     - virtual:
-#$$$$ Discussion open whether this is necessary here.
+      # $$$$ Discussion open whether this is necessary here.
       architecture: x86_64
       features:
         - xyz
 
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Discussion open how to specify the distribution of components on nodes.
-# Three proposals:
-# 1. specify availability options ha, noha by placing functions on nodes
-# 2. specify roles like compute-node, controller-node and only their number,
-#    thus avoid coupling with hostnames and more flexible mapping to different
-#    sizes of PODs. 
-# 3. Leave it to installers and just specify whether ha or noha are supported
-
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Proposal 1:
+  # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+  # Discussion open how to specify the distribution of components on nodes.
+  # Three proposals:
+  # 1. specify availability options ha, noha by placing functions on nodes
+  # 2. specify roles like compute-node, controller-node and only their number,
+  #    thus avoid coupling with hostnames and more flexible mapping to different
+  #    sizes of PODs.
+  # 3. Leave it to installers and just specify whether ha or noha are supported
+  # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+  # Proposal 1:
   availability:                 # mandatory
-# here the configuration for a HA and NONHA deployment is described.
-# It is similar to what compass has in host section (minus the POD info),
-# or fuel in the dea-override-config or dha-override-config
+    # here the configuration for a HA and NONHA deployment is described.
+    # It is similar to what compass has in host section (minus the POD info),
+    # or fuel in the dea-override-config or dha-override-config
     - ha:                       # minimum one of ha or noha must be specified
         nodes:                  # a description like this is mandatory
-          - name: [host1, host2, host3] # avoid to list the same multiple times
+          - name: [host1, host2, host3]  # avoid to list the same multiple times
             roles:
-              - openstack-controller # took this from compass. Is it sufficient?
+              # took this from compass. Is it sufficient?
+              - openstack-controller
               - odl
               - ceph-adm
               - ceph-mon
@@ -204,11 +213,11 @@ deployment-options:             # mandatory
               - openstack-compute
               - ceph-osd
 
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Proposal 2:
-  roles:                        # mandatory
+  # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+  # Proposal 2:
+  roles:              # mandatory
     - controller-node:
-        components:             # list all components that are deployed here.
+        components:   # list all components that are deployed here.
           - openstack: control
           - opendaylight
           - ceph: [ceph-adm, ceph-mon]
@@ -220,9 +229,9 @@ deployment-options:             # mandatory
           - ovs
         hardware-features:
           - dpdk
-    - jump-host:                # some scenarios, e.g. MANO might deploy components here
+    - jump-host:      # some scenarios, e.g. MANO might deploy components here
 
-  role-distribution:            # mandatory
+  role-distribution:  # mandatory
     - ha:
         controller-node: 3
         compute-node: 2
@@ -232,37 +241,37 @@ deployment-options:             # mandatory
         compute-node: 4
         jump-host: 1
 
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Proposal 3:
-# no specification of nodes/roles here. ha, noha are defined by installers
+  # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+  # Proposal 3:
+  # no specification of nodes/roles here. ha, noha are defined by installers
 
   deployment-tools:             # mandatory
-# In the section for each deployment tool, the combinations of the
-# first three options have to be listed. CI can pick any of the sections.
+    # In the section for each deployment tool, the combinations of the
+    # first three options have to be listed. CI can pick any of the sections.
     - fuel:                     # at least one section
-         cpu: intel             # optional, default = intel
-         pod: baremetal
-         availability: ha
+        cpu: intel             # optional, default = intel
+        pod: baremetal
+        availability: ha
     - fuel:
-         cpu: intel
-         pod: virtual
-         availability: ha
+        cpu: intel
+        pod: virtual
+        availability: ha
     - fuel:
-         cpu: intel
-         pod: virtual
-         availability: noha
+        cpu: intel
+        pod: virtual
+        availability: noha
     - fuel:
-         cpu: arm
-         pod: baremetal
-         availability: noha
+        cpu: arm
+        pod: baremetal
+        availability: noha
     - compass:
-         cpu: intel
-         pod: baremetal
-         availability: ha
+        cpu: intel
+        pod: baremetal
+        availability: ha
     - joid:
-         cpu: intel
-         pod: baremetal
-         availability: ha
+        cpu: intel
+        pod: baremetal
+        availability: ha
 
 ##############################################################################