...
Source | Destination |
|---|---|
| certificate of calico-etcd-<podname>-node1 | .values.nodes[0].tls.client.cert |
| certificate-key calico-etcd-<podname>-node1 | .values.nodes[0].tls.client.key |
| certificate of calico-etcd-<podname>-node1-peer | .values.nodes[0].tls.peer.cert |
| certificate-key of calico-etcd-<podname>-node1-peer | .values.nodes[0].tls.peer.key |
| certificate of calico-etcd-<podname>-node2 | .values.nodes[1].tls.client.cert |
| certificate-key calico-etcd-<podname>-node2 | .values.nodes[1].tls.client.key |
| certificate of calico-etcd-<podname>-node2-peer | .values.nodes[1].tls.peer.cert |
| certificate-key of calico-etcd-<podname>-node2-peer | .values.nodes[1].tls.peer.key |
| certificate of calico-etcd-<podname>-node3 | .values.nodes[2].tls.client.cert |
| certificate-key calico-etcd-<podname>-node3 | .values.nodes[2].tls.client.key |
| certificate of calico-etcd-<podname>-node3-peer | .values.nodes[2].tls.peer.cert |
| certificate-key of calico-etcd-<podname>-node3-peer | .values.nodes[2].tls.peer.key |
Undercloud Platform
TBA
Ceph
TBA
...
OpenStack Helm Infra
This includes configuring parameters of various infrastucture infrastructure components, such as elasticsearchas Elasticsearch, fluentbitFluentbit, fluentdFluentd, grafanaGrafana, ingressIngress, mariadbMariadb, prometheusand Prometheus.
User can leave all the values as is.
Open Stack OpenStack Helm - Compute Kit
Under this, there are three important configurations -
- Libvirt:
- Network Backend: openvswitch or sriovOpen vSwitch or SR-IOV.
- Neutron
- Nova
Tenant-Ceph
Config
Under this configuration, user can only set the region name for openstack helmOpenStack Helm.
| Parameter | sub-categorySubcategory | Description | Example - Value |
|---|---|---|---|
| osh | |||
| region_name | The region name to use. Typically Site name is provided. | intel-pod10 |
PKI-Catalog
| Parameter | sub-categorySubcategory-1 | sub-categorySubcategory-2 | Description | Example Value |
|---|---|---|---|---|
| certificate_authorities | ||||
| description | ||||
| certificates | ||||
| document_name | ||||
| description | ||||
| common_name | ||||
| hosts | ||||
| groups | ||||
| keypairs | ||||
| name | ||||
| description |
...
Boot actions can be more accurately described as post-deployment file placement. This file placement can be leveraged to install actions for servers to take after the permanent OS is installed and the server is rebooted. Including custom or vendor scripts and a SystemD service to run the scripts on first boot or on all boots allows almost any action to be configured.
| Parameter | SubSubcategory-Category-1 | subSubcategory-category-2 | Description | Example Value |
|---|---|---|---|---|
| signaling | whether Whether to expect a signal at the completion of this boot action. If set to true for a boot action that does not send a signal, it will elongate extend the deployment step and consider the boot action failed. | true | ||
| assets | A list of data assets. | |||
| items | ||||
| path | If type is unit - , it is a SystemD unit, such as a service, that will be saved to path and enabled via systemctl enable [filename] | |||
| location | (see data) | |||
| type | boot action framework supports assets of several types - 'unit','file', 'pkg_list' . pkg_list is a list of packages | 'file' | ||
| data | The asset contents can be sourced from either the in-document data field of the asset mapping or dynamically generated by requesting them from a URL provided in location. | |||
| location_pipeline | The boot action framework supports pipelines to allow for some dynamic rendering. There are separate pipelines for the location field to build the URL that referenced assets should be sourced from and the data field (or the data sourced from resolving the location field). | template | ||
| data_pipeline | The For 'template' - Treat the data element as a Jinja2 template and apply a node context to it. The defined context available to the template is below. | base64_encode', 'template', 'base64_decode', 'utf8_encode','utf8_decode' | ||
| permissions | If type is file. , it is simply saved to the filesystem at path and set with permissions. | |||
| node_filter | filter Filter for selecting to which nodes this boot action will apply. If no node filter is included, all nodes will receive the boot action. Otherwise, it will be is only the nodes that match the logic of the filter set. | |||
| filter_set_type | Either intersection|union | union | ||
| filter_set items | ||||
| filter_type | same Same as filter_set_type. | |||
| node_names | Names of the node. | |||
| node_tags | Node tags | |||
| node_labels | Node labels. | |||
| rack_names | Rack Names | |||
| rack_labels | Rack Labels |
Rack
| Parameter | Sub-CategorySubcategory | Description | Example Value |
|---|---|---|---|
| tor_switches | For one or more switches, define the following. | ||
| mgmt_ip | IP address of the management port | 1.1.1.1 | |
| sdn_api_uri | The URI for SDN based configuration | https://polo.opnfv.org/switchmgmt?switch=switch01name | |
| location | |||
| clli | Common Language Location Identifier Code - used within the North American telecommunications industry to specify the location and function of telecommunications equipment. | HSTNTXMOCG0 | |
| grid | The grid code. | EG12 | |
| local_networks* | Networks wholly contained to this rack. Nodes in a rack can only connect to local_networks of that rack | pxe_network1 |
Region
| Parameter | Sub-CategorySubcategory | Description | Example Value |
|---|---|---|---|
| tag_definitions* | |||
| tag | |||
| definition_type | lshw_xpath | ||
| definition | |||
| authorized_keys* | |||
| repositories | list List of SSH keys which MaaS will register for the built-in "ubuntu" account during the PXE process. This list is populated by substitution, so the same SSH keys do not need to be repeated in multiple manifests. | ||
| remove_unlisted | Whether to remove the unlisted packages? | true | |
| repo_type+ | |||
| url+ | |||
| distributions | |||
| subrepos | |||
| components | |||
| gpgkey | |||
| arches+ | |||
| options |
...
Generating certificates involves the following steps:
- 1. Get airship treasuremap to the jumpserver. git clone https://github.com/airshipit/treasuremap.git
- 2. copy type/cntt folder opnfv-airship to treasuremap under type
- 3. mv site defn. For pod10 to treasremaptreasuremap
- 4. sudo tools/airship pegleg site -r /target collect intel-pod10 -s intel-pod10_collected
- 5. mkdir intel-pod10_certs
- 6. sudo tools/airship promenade generate-certs -o /target/intel-pod10_certs /target/intel-pod10_collected/*.yaml
- 7. cp intel-pod10_certs/*.yaml site/intel-pod10/secrets/certificates/
- 8. mv site/intel-pod10 ../airship/site/
Publishing
TBA