Train Series Release Notes

19.0.4

Bug Fixes

• Bug 1855708: Reload broken in PY3

• Bug 1887994: Mixed message in admin docs to deploy under httpd

• Bug 1888349: glance-cache-manage utility is broken

• Bug 1886374: Improve lazy loading mechanism for multiple stores

19.0.2

Upgrade Notes

• The show_multiple_locations configuration option remains DEPRECATED but not removed in the Train release. We continue to recommend that image locations not be exposed to end users. See OSSN-0065 for more information.

  The plan continues to be to eliminate the option and use only policies to control image locations access. This, however, requires some major refactoring, as discussed in the draft Policy Refactor spec. Further, there is no projected timeline for this change, as no one has been able to commit time to it. (The Glance team would be happy to discuss this more with anyone interested in working on it.)

  Please keep a watch on the Glance release notes and the glance-specs repository to stay informed about developments on this issue.

19.0.0

Prelude

Train release includes multiple important milestones in Glance development priorities.

• Stabilization of multi-store feature; from Train onwards multi-store is considered stable feature in glance, glance_store and python-glanceclient. The community encourages everyone to adopt this new way of configuring backend stores at earliest convenience as the old configuration options are deprecated for removal to ease the burden of maintaining underlying code. Users are able to select the store they want their images to be stored during import process.

• glance-cache-manage and precaching is back; during the cycle we fixed issues that caused cache management being impossible. The prefetcher code was moved into glance-api to break the dependency to glance-registry and does not run under cron any more.

• Documentation examples were changed from openstack commands back to glance. This should help avoid the frustration of Glance-community maintaining different client than what is referred in examples. ‘python-glanceclient’ is and will be the reference implementation of Images API and the team will implement all API changes to the relevant client version of the cycle as well.

• This release also bumps the Images API CURRENT version to 2.9

New Features

• Train release includes a change to how cache prefetching works. As the prefetcher was one of the last components still relying to the glance-registry the requirement was removed by implementing the prefetcher as part of glance-api. Crontab based prefetcher is not available any more and the new prefetching will be set up through glance-api.conf.

• The identifier compressed has been added to the list of supported container formats. The intent is that this format identifier will be used for any compressed file archive format (for example, gzip or rar) that is not otherwise covered by the existing container format identifiers.

  As with all container formats, Glance does not verify that the data payload of an image is actually in that format. Further, you should not expect other OpenStack services to be able to handle arbitrary compressed file formats. Consult the documentation of any services that will consume your image for details.

• To support the Block Storage service (Cinder) upload-volume-to-image action when the volume is an encrypted volume type, when such an image is deleted, Glance will now contact the OpenStack Key Management service (Barbican) and request it to delete the associated encryption key. Two extra properties must be set on the image for this to work: cinder_encryption_key_id (whose value is the identifier in the OpenStack Key Management service for the encryption key used to encrypt the volume) and cinder_encryption_key_deletion_policy (whose value may be either on_image_deletion or do_not_delete). Please note the following:

  • An image created by the Block Storage service will have these properties set automatically, with the deletion policy set to on_image_deletion.

  • The Block Storage service always creates a new secret in Barbican when it uploads a volume as an image, keeping a 1-1 relation between each secret stored in the Key Management Service and each image of an encrypted volume stored in Glance. Thus, deleting the Barbican secret at the time when the image is deleted will not cause data loss as long as the secret is not being used for any other purpose.

    • The Block Storage service will not use the secret associated with an image for any other purpose.

    • If you choose to use the Barbican secret identified by the value of cinder_encryption_key_id for any other purpose, you risk data loss.

    • Manual use of the cinder_encryption_key_* properties is not recommended.

  • If the cinder_encryption_key_deletion_policy image property is missing or has any value other than on_image_deletion, Glance will not attempt to delete the key whose identifier is the value of cinder_encryption_key_id.

• The glance-scrubber utility is now multistore aware. If you are using the multistore feature, you must define configuration options for os_glance_tasks_store and os_glance_staging_store in the glance-scrubber.conf file. See the “Reserved Stores” section of the “Multi Store Support” chapter of the Glance Administration Guide for more information.

• It is now possible for Glance to use backends accessed via the glance_store library for the temporary storage of data that previously required access to the local filesystem. Please note the following:

  • In this release, the use of stores (instead of configuring the path directly) is optional, but it will become mandatory for the ‘U’ release.

  • In this release, the stores used must be the filesystem store type. Our goal is that in a future release, operators will be able to configure a store type from other selected drivers as well. In Train, however, each of these must be a filesystem store.

  Please see the Upgrades section of this document and the “Multi Store Support” chapter of the Glance Administration Guide for more information.

Known Issues

• The introduction of the compressed container format in this release gives us the opportunity to remind you that Glance does not verify that the container_format image property is accurate for any container format. It is the responsibility of the image consumer to verify the image data payload format and take appropriate action in the case of a misdescribed image.

• The intent of the compressed container format identifier introduced in this release is that it will be used for any compressed file archive format (for example, gzip or rar) that is not otherwise covered by the existing container format identifiers.

  The exact format of the compressed file is unspecified. It is the responsibility of the consuming service to analyse the data payload and determine the compression format. A particular OpenStack service may only support specific formats. Thus, even if a service does support the compressed container format, this does not imply that the service can handle arbitrary compression formats. Consult the documentation for the service that will consume your image for details.

• As of this release, the only service using the compressed container format is Cinder (Block Storage Service), when Cinder is configured to use compression when uploading a volume-image to Glance. While you may expect that Cinder will be able to consume any image in compressed container format that Cinder has created, you should not expect Cinder to be able to successfully use an image in compressed format that it has not created itself. Consult the Cinder documentation for more information.

• When using the multiple stores feature, each filesystem store must be configured with a different value for the filesystem_store_datadir option. This is not currently enforced in the code.

Upgrade Notes

• Location metadata key backend has been changed to store. Any environment that might be using the old backend key will have the key name changed through lazy update upon access.

• The identifier compressed has been added to the list of supported container formats. The intent is that this format identifier will be used for any compressed file archive format (for example, gzip or rar) that is not otherwise covered by the existing container format identifiers.

  The compressed container format was added in support of the Cinder (Block Storage Service) feature Leverage compression accelerator. You may expect that Cinder will be able to consume any image in compressed container format that Cinder has created. You should not expect, however, for other services to be able to consume such an image at the present time. Further, you should not expect Cinder to be able to successfully use an image in compressed format that it has not created itself.

• The properties cinder_encryption_key_id and cinder_encryption_key_deletion_policy have been added to the common image properties and appear in the image schema. See the “New Features” section of these notes for information about these image properties.

• If you are using the multistore feature, you must define configuration options for os_glance_tasks_store and os_glance_staging_store in the glance-scrubber.conf file. See the “Reserved Stores” section of the “Multi Store Support” chapter of the Glance Administration Guide for more information.

• The configuration options work_dir and node_staging_uri are deprecated and will be removed early in the ‘U’ development cycle.

  These local directories are used by Glance for the temporary storage of data during the interoperable image import process and by the tasks engine. This release introduces the ability to instead use a backend filesystem store accessed via the glance_store library for this temporary storage. Please note the following:

  • If you wish to use the backend store feature now, please see the “Reserved Stores” section of the “Multi Store Support” chapter of the Glance Administration Guide for configuration information.

  • If you use the Glance multiple stores feature, introduced on an experimental basis in Rocky and now fully supported in the Train release, then you must use backing stores instead of work_dir and node_staging_uri for Glance’s temporary storage beginning right now with the current release. See the “Reserved Stores” section of the “Multi Store Support” chapter of the Glance Administration Guide for more information.

• The store name prefix os_glance_* is reserved by Glance for internal stores. Glance will refuse to start if a store with this prefix is included in the enabled_backends option.

  The internal store identifiers introduced in this release are os_glance_tasks_store and os_glance_staging_store.

• The following metadata definitions have been modified in the Train release:

  • Added hw:mem_encryption boolean in the OS::Nova::Flavor namespace, and hw_mem_encryption boolean in the OS::Glance::Image namespace.

  • Added hw_pmu boolean, and hw_cdrom_bus and hw_firmware_type enumerations in the OS::Compute::LibvirtImage namespace.

  • Added powervm to the hypervisor_type enumeration in the OS:::Compute::Hypervisor namespace.

  • Added virtio, gop and none to the hw_video_model enumeration in the OS::Compute::LibvirtImage namespace.

  You may upgrade these definitions using:

  glance-manage db load_metadefs [--path <path>] [--merge] [--prefer_new]

Bug Fixes

• Bug 1836140: Image deletion returns 500 if ‘file’ store is not enabled

• • Bug 1808868: Add SEV-related extra spec and image properties

  • Bug 1802587: Make location API compatible with multiple store