|
| 1 | +# OSP 17.1 scenarios |
| 2 | + |
| 3 | +The files stored in this folder define different osp 17.1 deployments to be |
| 4 | +tested with adoption. For each scenario, we have a <scenario_name>.yaml file |
| 5 | +and folder with the same name. The yaml file contains variables that will be |
| 6 | +used to customize the scenario, while the folder contains files that will be |
| 7 | +used in the deployment (network_data, role files, etc.). |
| 8 | + |
| 9 | +This scenario definition assumes that all relevant parameters to the |
| 10 | +deployment are known, with the exception of infra-dependent values like ips or |
| 11 | +hostnames. |
| 12 | + |
| 13 | +## Scenario definition file |
| 14 | + |
| 15 | +The scenario definition file (the <scenario_name>.yaml) has the following top |
| 16 | +level sections: |
| 17 | + |
| 18 | +- `undercloud` |
| 19 | +- `stacks` |
| 20 | +- `cloud_domain` |
| 21 | +- `hostname_groups_map` |
| 22 | +- `roles_groups_map` |
| 23 | +- `hooks` |
| 24 | + |
| 25 | +### Undercloud section |
| 26 | + |
| 27 | +The undercloud section contains the following parameters (all optional): |
| 28 | + |
| 29 | +- `config`: a list of options to set in `undercloud.conf` file, each entry is |
| 30 | +a dictionary with the fields `section`, `option` and `value`. |
| 31 | +- `undercloud_parameters_override`: path to a file that contains some parameters |
| 32 | +for the undercloud setup, is passed through the `hieradata_override` option in |
| 33 | +the `undercloud.conf`. |
| 34 | +- `undercloud_parameters_defaults`: path to a file that contains |
| 35 | +parameters_defaults for the undercloud, is passed through the `custom_env_files` |
| 36 | +option in the `undercloud.conf`. |
| 37 | + |
| 38 | +### Stacks section |
| 39 | + |
| 40 | +The stacks section contains list of stacks to be deployed. Typically, this will |
| 41 | +be just one, commonly known as `overcloud`, but there can be arbitrarily many. |
| 42 | +For each entry the following parameters can be passed: |
| 43 | + |
| 44 | +- `stackname`: name of the stack deployment, default is `overcloud`. |
| 45 | +- `args`: list of cli arguments to use when deploying the stack. |
| 46 | +- `vars`: list of environment files to use when deploying the stack. |
| 47 | +- `network_data_file`: path to the network_data file that defines the network |
| 48 | +to use in the stack, required. This file can be a yaml or jinja file. It it |
| 49 | +ends with `j2`, it will be treated as a template, otherwise it'll be copied as |
| 50 | +is. |
| 51 | +- `vips_data_file`: path to the file defining the virtual ips to use in the |
| 52 | +stack, required. |
| 53 | +- `roles_file`: path to the file defining the roles of the different nodes |
| 54 | +used in the stack, required. |
| 55 | +- `config_download_file`: path to the config-download file used to pass |
| 56 | +environment variables to the stack, required. |
| 57 | +- `ceph_osd_spec_file`: path to the osd spec file used to deploy ceph when |
| 58 | +applicable, optional. |
| 59 | +- `deploy_command`: string with the stack deploy command to run verbatim, |
| 60 | +if defined, it ignores the `vars` and `args` fields, optional. |
| 61 | +- `stack_nodes`: list of groups for the inventory that contains the nodes that |
| 62 | +will be part of the stack, required. This groups must be a subset of the groups |
| 63 | +used as keys in `hostname_groups_map` and `roles_groups_map`. |
| 64 | + |
| 65 | +### Cloud domain |
| 66 | + |
| 67 | +Name of the dns domain used for the overcloud, particularly relevant for tlse |
| 68 | +environments. |
| 69 | + |
| 70 | +### Hostname groups map |
| 71 | + |
| 72 | +Map that relates ansible groups in the inventory produced by the infra creation |
| 73 | +to role hostname format for 17.1 deployment. This allows to tell which nodes |
| 74 | +belong to the overcloud without trying to rely on specific naming. Used to |
| 75 | +build the hostnamemap. For example, let's assume that we have an inventory with |
| 76 | +a group called `osp-computes` that contains the computes, and a group called |
| 77 | +`osp-controllers` that contains the controllers, then a possible map would look |
| 78 | +like: |
| 79 | + |
| 80 | +``` |
| 81 | +hostname_groups_map: |
| 82 | + osp-computes: "overcloud-novacompute" |
| 83 | + osp-controllers: "overcloud-controller" |
| 84 | +``` |
| 85 | + |
| 86 | +### Roles groups map |
| 87 | + |
| 88 | +Map that relates ansible groups in the inventory produced by the infra creation |
| 89 | +to OSP roles. This allows to build a tripleo-ansible-inventory which is used, |
| 90 | +for example, to deploy Ceph. Continuing from the example mentioned in the |
| 91 | +previous section, a possible value for this map would be: |
| 92 | + |
| 93 | +``` |
| 94 | +hostname_groups_map: |
| 95 | + osp-computes: "Compute" |
| 96 | + osp-controllers: "Controller" |
| 97 | +``` |
| 98 | + |
| 99 | +### Hooks |
| 100 | + |
| 101 | +Hooks are a mechanism used in the ci-framework to run external code without |
| 102 | +modifying the project's playbooks. See the [ci-framework |
| 103 | +docs](https://ci-framework.readthedocs.io/en/latest/roles/run_hook.html) for |
| 104 | +more details about how hooks are used in the ci-framework. |
| 105 | + |
| 106 | +For deployment of osp 17.1, the following hooks are available: |
| 107 | + |
| 108 | +- `pre_uc_run`, runs before deploying the undercloud |
| 109 | +- `post_uc_run`, runs after deploying the undercloud |
| 110 | +- `pre_oc_run`, runs before deploying the overcloud, but after provisioning |
| 111 | +networks and virtual ips |
| 112 | +- `post_oc_run`, runs after deploying the overcloud |
| 113 | + |
| 114 | +Hooks provide flexibility to the users without adding too much complexity to |
| 115 | +the ci-framework. An example of use case of hooks here, is to deploy ceph for |
| 116 | +the scenarios that require it. Instead of having some flag in the code to |
| 117 | +select whether we should deploy it or not, we can deploy it using the |
| 118 | +`pre_oc_run`, like this: |
| 119 | + |
| 120 | +``` |
| 121 | +pre_oc_run: |
| 122 | + - name: Deploy Ceph |
| 123 | + type: playbook |
| 124 | + source: "adoption_deploy_ceph.yml" |
| 125 | +``` |
| 126 | + |
| 127 | +Since the `source` attribute is not an absolute path, this example assumes that |
| 128 | +the `adoption_deploy_ceph.yml` playbook exists in the ci-framework (it |
| 129 | +introduced alongside the role to consume the scenarios defined here by |
| 130 | +[this PR](https://github.com/openstack-k8s-operators/ci-framework/pull/2297)). |
0 commit comments