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 anymore.Documentation examples were changed from
openstack
commands back toglance
. 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 anymore 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) andcinder_encryption_key_deletion_policy
(whose value may be eitheron_image_deletion
ordo_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 thanon_image_deletion
, Glance will not attempt to delete the key whose identifier is the value ofcinder_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
andos_glance_staging_store
in theglance-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 thecontainer_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 analyze 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 incompressed
container format that Cinder has created, you should not expect Cinder to be able to successfully use an image incompressed
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 tostore
. Any environment that might be using the oldbackend
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 incompressed
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 incompressed
format that it has not created itself.
The properties
cinder_encryption_key_id
andcinder_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
andos_glance_staging_store
in theglance-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
andnode_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
andnode_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 theenabled_backends
option.The internal store identifiers introduced in this release are
os_glance_tasks_store
andos_glance_staging_store
.
The following metadata definitions have been modified in the Train release:
Added
hw:mem_encryption
boolean in theOS::Nova::Flavor
namespace, andhw_mem_encryption
boolean in theOS::Glance::Image
namespace.Added
hw_pmu
boolean, andhw_cdrom_bus
andhw_firmware_type
enumerations in theOS::Compute::LibvirtImage
namespace.Added
powervm
to thehypervisor_type
enumeration in theOS:::Compute::Hypervisor
namespace.Added
virtio
,gop
andnone
to thehw_video_model
enumeration in theOS::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