aboutsummaryrefslogtreecommitdiffstats
path: root/puppet-barometer/manifests/config.pp
blob: 8f620af9fd36ecd2a1a29fa74b3accc0f1c9c70e (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
# == Class: barometer::config
#
# This class is used to manage arbitrary barometer configurations.
#
# === Parameters
#
# [*barometer_config*]
#   (optional) Allow configuration of arbitrary barometer configurations.
#   The value is an hash of barometer_config resources. Example:
#   { 'DEFAULT/foo' => { value => 'fooValue'},
#     'DEFAULT/bar' => { value => 'barValue'}
#   }
#   In yaml format, Example:
#   barometer_config:
#     DEFAULT/foo:
#       value: fooValue
#     DEFAULT/bar:
#       value: barValue
#
#   NOTE: The configuration MUST NOT be already handled by this module
#   or Puppet catalog compilation will fail with duplicate resources.
#
class barometer::config (
  $barometer_config = {},
) {

  validate_hash($barometer_config)

  create_resources('barometer_config', $barometer_config)
}
ance */ .highlight .vm { color: #f8f8f2 } /* Name.Variable.Magic */ .highlight .il { color: #ae81ff } /* Literal.Number.Integer.Long */ } @media (prefers-color-scheme: light) { .highlight .hll { background-color: #ffffcc } .highlight .c { color: #888888 } /* Comment */ .highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */ .highlight .k { color: #008800; font-weight: bold } /* Keyword */ .highlight .ch { color: #888888 } /* Comment.Hashbang */ .highlight .cm { color: #888888 } /* Comment.Multiline */ .highlight .cp { color: #cc0000; font-weight: bold } /* Comment.Preproc */ .highlight .cpf { color: #888888 } /* Comment.PreprocFile */ .highlight .c1 { color: #888888 } /* Comment.Single */ .highlight .cs { color: #cc0000; font-weight: bold; background-color: #fff0f0 } /* Comment.Special */ .highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */ .highlight .ge { font-style: italic } /* Generic.Emph */ .highlight .gr { color: #aa0000 } /* Generic.Error */ .highlight .gh { color: #333333 } /* Generic.Heading */ .highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */ .highlight .go { color: #888888 } /* Generic.Output */ .highlight .gp { color: #555555 } /* Generic.Prompt */ .highlight .gs { font-weight: bold } /* Generic.Strong */ .highlight .gu { color: #666666 } /* Generic.Subheading */ .highlight .gt { color: #aa0000 } /* Generic.Traceback */ .highlight .kc { color: #008800; font-weight: bold } /* Keyword.Constant */ .highlight .kd { color: #008800; font-weight: bold } /* Keyword.Declaration */ .highlight .kn { color: #008800; font-weight: bold } /* Keyword.Namespace */ .highlight .kp { color: #008800 } /* Keyword.Pseudo */ .highlight .kr { color: #008800; font-weight: bold } /* Keyword.Reserved */ .highlight .kt { color: #888888; font-weight: bold } /* Keyword.Type */ .highlight .m { color: #0000DD; font-weight: bold } /* Literal.Number */ .highlight .s { color: #dd2200; background-color: #fff0f0 } /* Literal.String */ .highlight .na { color: #336699 } /* Name.Attribute */ .highlight .nb { color: #003388 } /* Name.Builtin */ .highlight .nc { color: #bb0066; font-weight: bold } /* Name.Class */ .highlight .no { color: #003366; font-weight: bold } /* Name.Constant */ .highlight .nd { color: #555555 } /* Name.Decorator */ .highlight .ne { color: #bb0066; font-weight: bold } /* Name.Exception */ .highlight .nf { color: #0066bb; font-weight: bold } /* Name.Function */ .highlight .nl { color: #336699; font-style: italic } /* Name.Label */ .highlight .nn { color: #bb0066; font-weight: bold } /* Name.Namespace */ .highlight .py { color: #336699; font-weight: bold } /* Name.Property */ .highlight .nt { color: #bb0066; font-weight: bold } /* Name.Tag */ .highlight .nv { color: #336699 } /* Name.Variable */ .highlight .ow { color: #008800 } /* Operator.Word */ .highlight .w { color: #bbbbbb } /* Text.Whitespace */ .highlight .mb { color: #0000DD; font-weight: bold } /* Literal.Number.Bin */ .highlight .mf { color: #0000DD; font-weight: bold } /* Literal.Number.Float */ .highlight .mh { color: #0000DD; font-weight: bold } /* Literal.Number.Hex */ .highlight .mi { color: #0000DD; font-weight: bold } /* Literal.Number.Integer */ .highlight .mo { color: #0000DD; font-weight: bold } /* Literal.Number.Oct */ .highlight .sa { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Affix */ .highlight .sb { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Backtick */ .highlight .sc { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Char */ .highlight .dl { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Delimiter */ .highlight .sd { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Doc */ .highlight .s2 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Double */ .highlight .se { color: #0044dd; background-color: #fff0f0 } /* Literal.String.Escape */ .highlight .sh { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Heredoc */ .highlight .si { color: #3333bb; background-color: #fff0f0 } /* Literal.String.Interpol */ .highlight .sx { color: #22bb22; background-color: #f0fff0 } /* Literal.String.Other */ .highlight .sr { color: #008800; background-color: #fff0ff } /* Literal.String.Regex */ .highlight .s1 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Single */ .highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */ .highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */ .highlight .vc { color: #336699 } /* Name.Variable.Class */ .highlight .vg { color: #dd7700 } /* Name.Variable.Global */ .highlight .vi { color: #3333bb } /* Name.Variable.Instance */ .highlight .vm { color: #336699 } /* Name.Variable.Magic */ .highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */ }
---
##############################################################################
# Copyright (c) 2017 Huawei and others.
# ulrich.kleber@huawei.com
# All rights reserved. This program and the accompanying materials
# are made available under the terms of the Apache License, Version 2.0
# which accompanies this distribution, and is available at
# http://www.apache.org/licenses/LICENSE-2.0
##############################################################################

##############################################################################
# Description:
# This is the template for all scenario descriptor files (sdf)
# Every OPNFV scenario is described in an sdf.yaml located in the
# scenarios folder in Octopus repo.
# The sdf is provided by the scenario owner and consumed by CI, deployment
# tools and test frameworks.
#
# Main sections:
#
# metadata (owner, history, description)
# list of components (names, versions, submodules)
# 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-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.
  title: "SDF template"         # mandatory
  # 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
  # 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
  opnfv-version:
    - begins: 5.1.0             # mandatory
    # 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
# author of this file and thus owner of the scenario
# Add additional contact persons e.g. from installers or major components

##############################################################################

##############################################################################
# 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.
  - 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

  - 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
      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.
      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.
        - 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.
        - aodh
        - tacker
        - congress

  - 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
      version: 2.6.1
      features:             # optional
        - vsperf:
            file: scenarios/ovs-config.yaml
# this file then should contain additional configurations to use like
# hugepage-size, iommu, ...
# it will be treated like a C #include statement.
# 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.
##############################################################################

##############################################################################
# deployment options
# In this section, CI will select one of the listed options and needs to pass
# the information to the installer via a parameter or environment.
deployment-options:             # mandatory
  deployment-types:             # at least one section must be provided
    - baremetal:
      architecture: x86_64
      features:                 # optional
        - dpdk
        - other
    # $$$$ Discussion open whether we need features here after adding
    # them in roles section
    - baremetal:
      architecture: arm64
    - virtual:
      # $$$$ 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:
  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
    - 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
            roles:
              # took this from compass. Is it sufficient?
              - openstack-controller
              - odl
              - ceph-adm
              - ceph-mon
          - name: [host4, host 5]
            roles:
              - openstack-compute
              - ceph-osd
    - noha:
        hosts:
          - name: host1
            roles:
              - openstack-controller
              - odl
              - ceph-adm
              - ceph-mon
          - name: host2
            roles:
              - openstack-compute
              - ceph-osd
          - name: host3
            roles:
              - openstack-compute
              - ceph-osd

  # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
  # Proposal 2:
  roles:              # mandatory
    - controller-node:
        components:   # list all components that are deployed here.
          - openstack: control
          - opendaylight
          - ceph: [ceph-adm, ceph-mon]
          - ovs
    - compute-node:
        components:
          - openstack: compute
          - ceph: ceph-osd
          - ovs
        hardware-features:
          - dpdk
    - jump-host:      # some scenarios, e.g. MANO might deploy components here

  role-distribution:  # mandatory
    - ha:
        controller-node: 3
        compute-node: 2
        jump-host: 1
    - noha:
        controller-node: 1
        compute-node: 4
        jump-host: 1

  # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
  # 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.
    - fuel:                     # at least one section
        cpu: intel             # optional, default = intel
        pod: baremetal
        availability: ha
    - fuel:
        cpu: intel
        pod: virtual
        availability: ha
    - fuel:
        cpu: intel
        pod: virtual
        availability: noha
    - fuel:
        cpu: arm
        pod: baremetal
        availability: noha
    - compass:
        cpu: intel
        pod: baremetal
        availability: ha
    - joid:
        cpu: intel
        pod: baremetal
        availability: ha

##############################################################################

##############################################################################
# Prerequisites
# This section will list additional prerequisites. Currently there is only
# one case where a scenario has additional prerequisites to the Pharos spec.
# Open-O deployment requires 64GB of memory while Pharos spec requires 32GB.
# In general it should be preferred to issue such requirements to pharos
# using the pharos change request process, but in some cases in might be
# better to specify additional prerequisites.
# Another use case for these prerequisites will be usage of specilized
# hardware, e.g. for acceleration. This needs further study.

prerequisites:                  # The section can be empty or omitted.
  - controller-node:            # Prerequisites might be different
      RAM: 128GB                # optional, just to give examples
      cpu: dual-core
      features:                 # optional, see example below
  - compute-node:
      RAM: 128GB
      cpu: dual-core
      features:
        - dpdk
  - jumphost:                   # Prerequisites can be given also for jumphost
      RAM: 128GB
      cpu: dual-core

##############################################################################