aboutsummaryrefslogtreecommitdiffstats
path: root/puppet/services/ca-certs.yaml
blob: 735e6dde4dc5f42086d193038ac7908c82a0118b (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
heat_template_version: ocata

description: >
  HAproxy service configured with Puppet

parameters:
  ServiceNetMap:
    default: {}
    description: Mapping of service_name -> network name. Typically set
                 via parameter_defaults in the resource registry.  This
                 mapping overrides those in ServiceNetMapDefaults.
    type: json
  DefaultPasswords:
    default: {}
    type: json
  EndpointMap:
    default: {}
    description: Mapping of service endpoint -> protocol. Typically set
                 via parameter_defaults in the resource registry.
    type: json
  CAMap:
    description: >
      Map containing the CA certs and information needed for deploying them.
    default: {}
    type: json

outputs:
  role_data:
    description: Role data for injecting CA certificates.
    value:
      service_name: ca_certs
      config_settings:
        tripleo::trusted_cas::ca_map: {get_param: CAMap}
      step_config: |
        include ::tripleo::trusted_cas
=================================================+ | .. image:: ../images/weather-clear.jpg | Stable, no known issues | +---------------------------------------------+----------------------------------------------------------+ | .. image:: ../images/weather-few-clouds.jpg | Stable, documented limitations | +---------------------------------------------+----------------------------------------------------------+ | .. image:: ../images/weather-overcast.jpg | Deployable, stability or feature limitations | +---------------------------------------------+----------------------------------------------------------+ | .. image:: ../images/weather-dash.jpg | Not deployed with this installer | +---------------------------------------------+----------------------------------------------------------+ Scenarios that are not yet in a state of "Stable, no known issues" will continue to be stabilised and updates will be made on the stable/brahmaputra branch. While we intend that all Brahmaputra scenarios should be stable it is worth checking regularly to see the current status. Due to our dependency on upstream communities and code some issues may not be resolved prior to the C release. Scenario Naming ^^^^^^^^^^^^^^^ In OPNFV scenarios are identified by short scenario names, these names follow a scheme that identifies the key components and behaviours of the scenario. The rules for scenario naming are as follows: os-[controller]-[feature]-[mode]-[option] Details of the fields are * os: mandatory * Refers to the platform type used * possible value: os (OpenStack) * [controller]: mandatory * Refers to the SDN controller integrated in the platform * example values: nosdn, ocl, odl, onos * [feature]: mandatory * Refers to the feature projects supported by the scenario * example values: nofeature, kvm, ovs, sfc * [mode]: mandatory * Refers to the deployment type, which may include for instance high availability * possible values: ha, noha * [option]: optional * Used for the scenarios those do not fit into naming scheme. * The optional field in the short scenario name should not be included if there is no optional scenario. Some examples of supported scenario names are: * os-nosdn-kvm-noha * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor * os-onos-nofeature-ha * This is an OpenStack deployment in high availability mode including ONOS as the SDN controller * os-odl_l2-sfc * This is an OpenStack deployment using OpenDaylight and OVS enabled with SFC features Installing your scenario ^^^^^^^^^^^^^^^^^^^^^^^^ There are two main methods of deploying your target scenario, one method is to follow this guide which will walk you through the process of deploying to your hardware using scripts or ISO images, the other method is to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master. For the purposes of evaluation and development a number of Brahmaputra scenarios are able to be deployed virtually to mitigate the requirements on physical infrastructure. Details and instructions on performing virtual deployments can be found in the installer specific installation instructions. To set up a Jenkins slave for automated deployment to your lab, refer to the `Jenkins slave connect guide. <http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html>`_