Current Series Release Notes

18.0.0-70

New Features

  • Users can now specify roles_data.yaml and network_data.yaml locations in their answers file. Using networks and roles along with their templates and environments arguments.

Deprecation Notes

  • force-stack-update and force_stack_create cli arguments for undercloud/standalone deploy has been deprecated and are now irrelevant.

  • The –static-inventory argument to the openstack update/upgrade commands has been deprecated and would be ignored. The inventory generated in work_dir with update/upgrade prepare would be used instead.

  • The following [DEFAULT] options of undercloud.conf have been deprecated and have no effect, because the correponding services are no longer supported in Undercloud.

    • enable_cinder

    • enable_keystone

    • enable_swift

    • enable_swift_encryption

    • enable_telemetry

Other Notes

  • Replace non-inclusive blacklist and whitelist with exclude and include.

  • The overcloud config download command no longer works with Ephemeral Heat. We already have the ability to do the same thing using overcloud deploy using the –stack-only flag. As such, the overcloud config download command is being removed.

  • The –heat-type argument for openstack overcloud deploy no longer accepts a value of “installed”, as using an undercloud installed Heat to deploy the overcloud is no longer supported.

  • Remove upgrade converge. This step was required to converge the Heat stack information with the upgraded environment. With Ephemeral Heat, this is no longer necessary and we can remove it to reduce upgrade steps and complexity.

18.0.0

New Features

  • Expose the existing –reproduce-command from openstack tripleo deploy CLI in the Undercloud CLI commnads. A new CLI option –reproduce-command is available for the openstack undercloud install and openstack undercloud upgrade commands, which creates an script, named ansible-playbook-command.sh, in the Undercloud’s deployment artifacts directory. This script allows running the Ansible playbooks for deployment or upgrade in the same way the CLI command does.

  • The Admin Authorize command can now be targeted at specific nodes using ‘–limit’. It can also take a custom static-inventory using ‘–static-inventory’.

  • A new option –daemons for the “openstack overcloud ceph deploy” command has been added. This option may be used to define additional Ceph daemons that should be deployed at this stage. For instance, a generic Ceph daemons definition can be something like the following:

    ---
    ceph_nfs:
      cephfs_data: 'manila_data'
      cephfs_metadata: 'manila_metadata'
    ceph_rgw: {}
    ceph_ingress:
      tripleo_cephadm_haproxy_container_image: undercloud.ctlplane.mydomain.tld:8787/ceph/haproxy:2.3
      tripleo_cephadm_keepalived_container_image: undercloud.ctlplane.mydomain.tld:8787/ceph/keepalived:2.5.1
    

    For each service added to the data structure above, additional options can be defined and passed as extra_vars to the tripleo-ansible flow. If no option is specified, the default values provided by the cephadm tripleo-ansible role will be used.

  • Two new commands, “openstack overcloud ceph user enable” and “openstack overcloud ceph user disable” are added. The “enable” option will create the cephadm SSH user and distribute their SSH keys to Ceph nodes in the overcloud. The “disable” option may be run after “openstack overcloud ceph deploy” has been run to disable cephadm so that it may not be used to administer the Ceph cluster and no “ceph orch …” CLI commands will function. This will also prevent Ceph node overcloud scale operations though the Ceph cluster will still be able to read/write data. The “ceph user disable” option will also remove the public and private SSH keys of the cephadm SSH user on overclouds which host Ceph. The “ceph user enable” option may also be used to re-distribute the public and private SSH keys of the cephadm SSH user and re-enable the cephadm mgr module.

  • A new option –ceph-vip for the “openstack overcloud ceph deploy” command has been added. This option may be used to reserve VIP(s) for each Ceph service specified by the ‘service/network’ mapping defined as input. For instance, a generic ceph service mapping can be something like the following:

    ---
    ceph_services:
      - service: ceph_nfs
        network: storage_cloud_0
      - service: ceph_rgw
        network: storage_cloud_0
    

    For each service added to the list above, a virtual IP on the specified network is created to be used as frontend_vip of the ingress daemon. When no subnet is specified, a default <network>_subnet pattern is used. If the subnet does not follow the <network>_subnet pattern, a subnet for the VIP may be specified per service:

    ---
    ceph_services:
      - service: ceph_nfs
        network: storage_cloud_0
      - service: ceph_rgw
        network: storage_cloud_0
        subnet: storage_leafX
    

    When the subnet parameter is provided, it will be used by the ansible module, otherwise the default pattern is followed. This feature also supports the fixed_ips mode. When fixed_ip(s) are defined, the module is able to use that input to reserve the VIP on that network. A valid input can be something like the following:

    ---
    fixed: true
    ceph_services:
      - service: ceph_nfs
        network: storage_cloud_0
        ip_address: 172.16.11.159
      - service: ceph_rgw
        network: storage_cloud_0
        ip_address: 172.16.11.160
    

    When the boolean fixed is set to True, the subnet pattern is ignored, and a sanity check on the user input is performed, looking for the ip_address keys associated to the specified services. If the fixed keyword is missing, the subnet pattern is followed.

  • New command “openstack overcloud ceph spec” has been added. This command may be used to create a cephadm spec file as a function of the output of metalsmith and a TripleO roles file. For example, if metalsmith output a file with multiple hosts of differing roles and each role contained various Ceph services, then a cephadm spec file could parse these files and return input compatible with cephadm. The ceph spec file may be then be passed to “openstack overcloud ceph deploy” so that cephadm deploys only those Ceph services on those hosts. This feature should save users from the need to create two different files containing much of the same data and make it easier and less error prone to include Ceph in a deployment without the need to manually create the Ceph spec file.

  • The cli arguments that control what parts of the deployment to execute have been refactored to better align with the user expected intention, –stack-only: create the stack, download the config. no overcloud node changes –setup-only: ssh admin authorization setup. –config-download-only: run config-download playbook(s) to configure the overcloud.

Upgrade Notes

  • Removed overcloud container image upload, overcloud container image build, overcloud container image prepare and overcloud container image tag commands as the tripleo container command replaced those in Train and they no longer work.

Deprecation Notes

  • Ephemeral heat is now used as default for overcloud deployment and assumes the nodes are pre-provisioned using metalsmith. Deprecates existing --deployed-server option and adds an additional option --provision-nodes for using installed heat and provisioning nodes with heat.

  • The commands openstack overcloud profiles list and openstack overcloud profiles match has been deprecated for removal. Since the Compute service is no longer used on the undercloud, the flavors based scheduling is not used.

Bug Fixes

  • Fixes Admin Authorize to work with Ephemeral Heat.

  • Fixes incorrect handling of root device hints when Software RAID is in use with Ironic. Users may re-introspect and an automatic root device hint would be added, which is incorrect and can lead to a failed deployment due to Software RAID (MD) device names being inconsistent across reboot from being configured to utilized. Ironic ultimately understands these devices and should choose the correct device by default if present. We now log an Warning and do not insert a potentially incorrect root device hint. Operators using a complex set of disks may still need to explicitly set a root device hint should their operational state require it.

Other Notes

  • Stack outputs that are needed by other functionality of the overcloud deployment are now saved in the stack working directory in an outputs subdirectory (default ~/overcloud-deploy/<stack>/outputs).

17.1.0

Prelude

During a minor update of the overcloud. It was previously necessary to execute 3 steps. - Update Prepare - Update Run - Update Converge Starting in W, it is no longer necessary to perform a Stack update during the converge. This change removes the stack update from the converge step. Now, we will just run the deploy_steps_playbook instead.

New Features

  • Added options for “overcloud delete” command to unprovision networks provisioned with “overcloud deploy” or with “overcloud network provision”.

  • The commands openstack overcloud node import and openstack overcloud node configure now have a –boot-mode arguement which allows the boot mode for all affected nodes to be set to UEFI boot (uefi) or legacy BIOS boot (bios). This allows some nodes to have a different boot mode to the default (uefi).

  • The enable_mistral parameter and the enable_zaqar parameter in undercloud/standalone deployment have been deprecated and will be removed in a future release.

  • Neutron resources for overcloud deployments on the undercloud is now managed with tooling external to the Heat stack.

    Networks and subnet resources as well as Virtual IPs for an overcloud can either be manged using separate commands or the all-in-one overcloud deploy by using the new network data YAML definition as --networks-file and the --vip-file arguments with this command.

    Overcloud node network ports are now managed by the baremetal node provisioning workflow. Baremeteal nodes, and the network resources, can be provisioned using the separate overcloud node provision command. Alternatively the all-in-one overcloud deploy command will run the baremetal node provisioning steps if the --baremetal-deployment argument is used.

    Please refer to the Networking Version 2 (Two). documentation page for more details.

  • Undercloud is now deployed without keystone and deploys standalone openstack services with http_basic authentication. A new option ‘enable_keystone’ has been added to enable keystone in the undercloud if required.

  • An ephemeral Heat process is now used by default for overcloud deployment. On each overcloud management operation (deploy/update/upgrade), a containerized Heat process will be started, the stack will be created new, and then the Heat process will be stopped. The enable_heat option is undercloud.conf is now defaulted to False.

  • A new command “openstack overcloud ceph deploy” is added. The command is used to deploy Ceph after the hardware has been provisioned with networking and before the overcloud is deployed. The command takes the output of “openstack overcloud node provision” as input and returns a Heat enviornment file, e.g. deployed_ceph.yaml, as output. The deployed_ceph.yaml file may then be passed to the “openstack overcloud deploy” command as input. During overcloud deployment the Ceph cluster is then configured to host OpenStack. E.g. cephx keys and pools are still created on the Ceph cluster by “openstack overcloud deploy”.

Upgrade Notes

  • The following two options have been removed.

    • docker_registry_mirror

    • docker_insecure_registries

  • The container_cli parameter no longer accepts docker. Now only podman is accepted as a valid value.

  • The network data defintion used with the overcloud deployement must be updated to version 2. The undercloud upgrade will execute the command (openstack overcloud network extract) to generate the network data definition for each deployed overcloud. The undercloud upgrade will save the new file in the working directory for each stack, defaults to overcloud-deploy/<STACK_NAME>/tripleo-<STACK_NAME>-network-data.yaml.

  • A new YAML definition file for overcloud stack virtual IPs must be used. The undercloud upgrade will execute the command (overcloud network vip extract) to generate this file for each deployed overcloud. The undercloud upgrade will save the new file in the working directory for each stack, defaults to overcloud-deploy/< STACK_NAME>/tripleo-<STACK_NAME>-virtual-ips.yaml.

  • The baremetal node defintion has been extended to support neutron port resource managment, this requires additional input in the YAML definition used for baremetal node provisioning. The undercloud upgrade will execute the command (overcloud node extract provisioned) to generate this file for each deployed overcloud. The undercloud upgrade will save the new file in the working directory for each stack, defaults to overcloud-deploy/<STACK_NAME>/tripleo-<STACK_NAME>-baremetal-deployment.yaml.yaml.

  • keystone service would not be deployed by default in the undercloud.

Deprecation Notes

  • The --local argument to the openstack overcloud image upload command has been deprecated and a --no-local argument has been added. Earlier we used to fallback to upload locally when glance was not available. As glance is not installed in the undercloud by default, we would upload images locally unless --no-local is used.

  • The enable_novajoin parameter in undercloud/standalone deployment has been deprecated.

  • To enable management of neutron resources external to Heat the network data YAML definition schema has been updated. The previous schema version has been deprecated, using the deprecated v1 schema is only possible when the deprecated non-ephemeral Heat on the Undercloud.

  • Managing netron resources for composable networks is now enabled by default when provisioning baremetal nodes. The option --network-ports has been deprecated, and is a NOOP until it is fully removed.

  • Setting enable_heat=True in undercloud.conf is deprecated.

  • Using –heat-type=installed is deprecated with the openstack overcloud commands.

Other Notes

  • Removed –standalone from openstack tripleo deploy command.

17.0.0

New Features

  • New configuration options for enable_neutron and enable_heat are added to the standalone and undercloud installers. These options default to true, and can be used to selectively disable these services.

  • A new cli argument, –heat-type is added to openstack overcloud deploy. Available options are “installed”, “pod”, “container”, and “native”. The default is “installed”. The argument specifies the type of Heat process to use for the deployment.

  • Added options for “overcloud delete” command to unprovision nodes and network ports provisioned with “overcloud deploy”.

  • The “openstack tripleo deploy” and “openstack undercloud install” commands now save their generated artifacts from the deployment under a single consistent directory, which by default is located at ~/tripleo-deploy/<stack>. For the undercloud, this location is ~/tripleo-deploy/undercloud. The directory can be overridden with the –output-dir option.