Glance Release Notes - en to en_GB translation catalogue (79 entries)

en: A new common image property, 'description', has been added.  This allows you to specify a brief human-readable description, suitable for display in a user interface, on images.  It has been possible to do this previously using a custom image property; this change simply standardizes the usage in order to promote interoperability. This change has no effect on any property named 'description' on existing images, and it is not a required image property.
en_GB: A new common image property, 'description', has been added.  This allows you to specify a brief human-readable description, suitable for display in a user interface, on images.  It has been possible to do this previously using a custom image property; this change simply standardises the usage in order to promote interoperability. This change has no effect on any property named 'description' on existing images, and it is not a required image property.

en: A plugin framework for customizing the processing of imported images before they become active is introduced in this release, along with a new plugin that injects image metadata properties into imported images.
en_GB: A plugin framework for customising the processing of imported images before they become active is introduced in this release, along with a new plugin that injects image metadata properties into imported images.

en: A recent change to oslo.log (>= 3.17.0) set the default value of ``[DEFAULT]/use_stderr`` to ``False`` in order to prevent duplication of logs (as reported in bug \#1588051). Since this would change the current behaviour of certain glance commands (e.g., glance-replicator, glance-cache-manage, etc.), we chose to override the default value of ``use_stderr`` to ``True`` in those commands. We also chose not to override that value in any Glance service (e.g., glance-api, glance-registry) so that duplicate logs are not created by those services. Operators that have a usecase that relies on logs being reported on standard error may set ``[DEFAULT]/use_stderr = True`` in the appropriate service's configuration file upon deployment.
en_GB: A recent change to oslo.log (>= 3.17.0) set the default value of ``[DEFAULT]/use_stderr`` to ``False`` in order to prevent duplication of logs (as reported in bug \#1588051). Since this would change the current behaviour of certain glance commands (e.g., glance-replicator, glance-cache-manage, etc.), we chose to override the default value of ``use_stderr`` to ``True`` in those commands. We also chose not to override that value in any Glance service (e.g., glance-api, glance-registry) so that duplicate logs are not created by those services. Operators that have a use-case that relies on logs being reported on standard error may set ``[DEFAULT]/use_stderr = True`` in the appropriate service's configuration file upon deployment.

en: Added oslopolicy enforcer entrypoint making it possible to utilize oslopolicy-policy-generator to get uniform information about the policies. NOTE: Glance will require policy.json being present for any meaningful output.
en_GB: Added oslopolicy enforcer entrypoint making it possible to utilise oslopolicy-policy-generator to get uniform information about the policies. NOTE: Glance will require policy.json being present for any meaningful output.

en: Added support for cinder multiple stores.
en_GB: Added support for Cinder multiple stores.

en: Added support for sparse image upload for filesystem and rbd driver
en_GB: Added support for sparse image upload for filesystem and RBD driver

en: Added support for unified quotas using keystone limits
en_GB: Added support for unified quotas using Keystone limits

en: Added support to immediately start caching of an image.
en_GB: Added support to immediately start caching an image.

en: After upgrading, deployments using the cinder backend should update their config to specify a volume type. Existing images on those backends will be updated at runtime (lazily, when they are first read) to a location URL that includes the store and volume type information.
en_GB: After upgrading, deployments using the Cinder backend should update their config to specify a volume type. Existing images on those backends will be updated at runtime (lazily, when they are first read) to a location URL that includes the store and volume type information.

en: Also, the project reader role is ready to use. Users with reader role can only perform the read-only operations within their project. This role can be used for the audit purposes.
en_GB: Also, the project reader role is ready to use. Users with reader role can only perform the read-only operations within their project. This role can be used for audit purposes.

en: As is standard behavior for the image-list call, other filters may be applied to the request.  For example, to see the community images supplied by user ``931efe8a-0ad7-4610-9116-c199f8807cda``, the following call would be made: ``GET v2/images?visibility=community&owner=931efe8a-0ad7-4610-9116-c199f8807cda``
en_GB: As is standard behaviour for the image-list call, other filters may be applied to the request.  For example, to see the community images supplied by user ``931efe8a-0ad7-4610-9116-c199f8807cda``, the following call would be made: ``GET v2/images?visibility=community&owner=931efe8a-0ad7-4610-9116-c199f8807cda``

en: As per the revised SRBAC community goals, glance service is switching to new defaults by default in Antelope cycle, hence removing the deprecated ``enforce_secure_rbac`` option which is no longer needed. The ``enforce_secure_rbac`` option was introduced EXPERIMENTAL in Wallaby release for operators to opt into enforcing authorization based on common RBAC personas.
en_GB: As per the revised SRBAC community goals, the Glance service is switching to new defaults by default in the Antelope cycle, hence removing the deprecated ``enforce_secure_rbac`` option which is no longer needed. The ``enforce_secure_rbac`` option was introduced EXPERIMENTAL in the Wallaby release for operators to opt into enforcing authorisation based on common RBAC personas.

en: Automatic image conversion plugin for Interoperable Image Import. With this release operators can specify target image format and get all images created via the Image Import methods introduced in the Images API v2.6 converted automatically to that format. The feautre uses qemu-img under the hood which limits the source image formats that users can upload. Any image that fails the conversion when this plugin is enabled will fail the image creation.
en_GB: Automatic image conversion plugin for Interoperable Image Import. With this release operators can specify target image format and get all images created via the Image Import methods introduced in the Images API v2.6 converted automatically to that format. The feature uses qemu-img which limits the source image formats that users can upload. Any image that fails the conversion when this plugin is enabled will fail the image creation.

en: Bug 1749297_: Fix 500 from list-tasks call with postgresql
en_GB: Bug 1749297_: Fix 500 from list-tasks call with PostgreSQL

en: Bug 1808814_: admin docs: interoperable image import revision for stein
en_GB: Bug 1808814_: admin docs: interoperable image import revision for Stein

en: Bug 1856578_: docs: image schema customization restrictions
en_GB: Bug 1856578_: docs: image schema customisation restrictions

en: Bug 1861723_: Glance is listening on TCP socket before store initialization
en_GB: Bug 1861723_: Glance is listening on TCP socket before store initialisation

en: Bug 1876419_: Failed to parse json file /etc/glance/metadefs/compute-vmware.json
en_GB: Bug 1876419_: Failed to parse JSON file /etc/glance/metadefs/compute-vmware.json

en: Bug 1884587_: image import copy-image API should reflect proper authorization
en_GB: Bug 1884587_: image import copy-image API should reflect proper authorisation

en: Bug 1905672_: Non existing property protection file raises 500 Internal server error
en_GB: Bug 1905672_: Non-existing property protection file raises 500 Internal server error

en: Bug 1914826_: web download with invalid url does not report error
en_GB: Bug 1914826_: web download with invalid URL does not report error

en: Bug 1914826_: web-download with invalid url does not report error
en_GB: Bug 1914826_: web-download with invalid URL does not report error

en: Bug 1983279_: Cannot upload vmdk images due to unsupported vmdk format
en_GB: Bug 1983279_: Cannot upload VMDK images due to unsupported VMDK format

en: Deprecate the ``show_multiple_locations`` configuration option in favor of the existing Role Based Access Control (RBAC) for Image locations which uses ``policy.json`` file to define the appropriate rules.
en_GB: Deprecate the ``show_multiple_locations`` configuration option in favour of the existing Role Based Access Control (RBAC) for Image locations which uses ``policy.json`` file to define the appropriate rules.

en: 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.
en_GB: 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.

en: Dropped support for python 2.7
en_GB: Dropped support for Python 2.7

en: Due to some unresolved issues on consuming multiple backends work the stabilization of the feature has been pushed to Train and will stay EXPERIMENTAL on Stein.
en_GB: Due to some unresolved issues on consuming multiple backends work the stabilisation of the feature has been pushed to Train and will stay EXPERIMENTAL on Stein.

en: During upgrade from single cinder store to multiple cinder stores, legacy images location url will be updated to the new format with respect to the volume type configured in the stores. Legacy location url: cinder://<volume-id> New location url: cinder://<store-id>/<volume-id>
en_GB: During upgrade from single Cinder store to multiple Cinder stores, legacy images location URL will be updated to the new format with respect to the volume type configured in the stores. Legacy location URL: cinder://<volume-id> New location URL: cinder://<store-id>/<volume-id>

en: Existing authorization and policies will continue to work, but we encourage operators to review the new policies and consolidate any redundant overrides with the new defaults if possible. Please review the feature section above for more details.
en_GB: Existing authorisation and policies will continue to work, but we encourage operators to review the new policies and consolidate any redundant overrides with the new defaults if possible. Please review the feature section above for more details.

en: For the Newton release, this option will still be honored. However, it is important to update ``policy.json`` file for glance-api nodes. In particular, please consider updating the policies ``delete_image_location``, ``get_image_location`` and ``set_image_location`` as per your requirements. As this is an advanced option and prone to expose some risks, please check the policies to ensure security and privacy of your cloud.
en_GB: For the Newton release, this option will still be honoured. However, it is important to update ``policy.json`` file for glance-api nodes. In particular, please consider updating the policies ``delete_image_location``, ``get_image_location`` and ``set_image_location`` as per your requirements. As this is an advanced option and prone to expose some risks, please check the policies to ensure security and privacy of your cloud.

en: Glance no longer returns a 500 when 4 byte unicode characters are passed to the metadefs API.
en_GB: Glance no longer returns a 500 when 4 byte Unicode characters are passed to the metadefs API.

en: Glance to glance image import plugin. With this release users can import an image from an other glance server from an other opensatck region. The two glance services must use the same keystone service. The feature use the same keystone authentication token on both glance services and copy by default container_format, disk_format and customizable properties from source image ``['hw_', 'trait:', 'os_distro', 'os_secure_boot', 'os_type']``
en_GB: Glance to glance image import plugin. With this release, users can import an image from another Glance server from another OpenStack region. The two glance services must use the same keystone service. The feature use the same Keystone authentication token on both Glance services and copy by default container_format, disk_format and customizable properties from source image ``['hw_', 'trait:', 'os_distro', 'os_secure_boot', 'os_type']``

en: Glance uses the ``cursive`` library's functionality to verify digital signatures. To familiarize yourself with this new dependency and see the list of transitive dependencies visit http://git.openstack.org/cgit/openstack/cursive
en_GB: Glance uses the ``cursive`` library's functionality to verify digital signatures. To familiarise yourself with this new dependency and see the list of transitive dependencies visit http://git.openstack.org/cgit/openstack/cursive

en: If an image has a visiblity of 'private' when viewed in the v2 API, then that image will not accept members in the v1 API.  If a user wants to share such an image, the user can:
en_GB: If an image has a visibility of 'private' when viewed in the v2 API, then that image will not accept members in the v1 API.  If a user wants to share such an image, the user can:

en: If upgrade is conducted from PY27 where ssl connections has been terminated into glance-api, the termination needs to happen externally from now on.
en_GB: If upgrade is conducted from PY27 where SSL connections has been terminated into glance-api, the termination needs to happen externally from now on.

en: If you were previously aware of this option and were actually using it, we apologize for the inconvenience its removal will cause, but overall it will be better for everyone if policy configuration is confined to the policy configuration file and this backdoor is eliminated.  The migration path is to explictly mention the role you configured for this option in appropriate places in your policy configuration file.
en_GB: If you were previously aware of this option and were actually using it, we apologize for the inconvenience its removal will cause, but overall it will be better for everyone if policy configuration is confined to the policy configuration file and this backdoor is eliminated.  The migration path is to explicitly mention the role you configured for this option in appropriate places in your policy configuration file.

en: In order to preserve backward compatibilty with the current sharing workflow, the default visibility of an image in Ocata is 'shared'. Consistent with pre-Ocata behavior, this will allow the image to accept member operations without first updating the visibility of the image. (Keep in mind that an image with visibility 'shared' but having no members is not actually accessible to anyone other than the image owner, so this is not in itself a security problem.)
en_GB: In order to preserve backward compatibility with the current sharing workflow, the default visibility of an image in Ocata is 'shared'. Consistent with pre-Ocata behaviour, this will allow the image to accept member operations without first updating the visibility of the image. (Keep in mind that an image with visibility 'shared' but having no members is not actually accessible to anyone other than the image owner, so this is not in itself a security problem.)

en: Multiple back-ends: No default back-end gets assigned when adding location via the locations api and not defining back-end ID on the call. This might affect specially Nova snapshots utilizing rdb back-end.
en_GB: Multiple back-ends: No default back-end gets assigned when adding location via the locations API and not defining back-end ID on the call. This might affect specially Nova snapshots utilising RDB back-end.

en: New Interoperable Image Import plugin has been introduced to address the use case of providing compressed images either through 'web-download' or to optimize the network utilization between the client and Glance.
en_GB: New Interoperable Image Import plugin has been introduced to address the use case of providing compressed images either through 'web-download' or to optimise the network utilisation between the client and Glance.

en: Note the code name for the "ceph" driver is ``rbd``.
en_GB: Note the code name for the "Ceph" driver is ``rbd``.

en: OpenStack deployments, packagers, and deployment projects which provided Glare should have begun to consume Glare from its own `Glare`_ respository during the Newton and Ocata releases.  With the Pike release, it is no longer possible to consume Glare code from the Glance repository.
en_GB: OpenStack deployments, packagers, and deployment projects which provided Glare should have begun to consume Glare from its own `Glare`_ repository during the Newton and Ocata releases.  With the Pike release, it is no longer possible to consume Glare code from the Glance repository.

en: Periodic job to prefetch image(s) into cache has been removed from the glance api service with config option ``cache_prefetcher_interval`` which was added as an interval for the same periodic job also been removed as image(s) will be immediately queued for caching.
en_GB: Periodic job to prefetch image(s) into cache has been removed from the Glance API service with config option ``cache_prefetcher_interval`` which was added as an interval for the same periodic job also been removed as image(s) will be immediately queued for caching.

en: Please note a change in the Scrubber's behavior in case of job fetching errors:
en_GB: Please note a change in the Scrubber's behaviour in case of job fetching errors:

en: Some security aspects were tackled for this release. Multihash, providing secure hashing for image data with future proof options marks the end of relying upon MD5 checksums when verifying image payloads. OSSN-0075 migitation lessens the risk of ID reusability on those very rare cases when a database purge is necessary.
en_GB: Some security aspects were tackled for this release. Multihash, providing secure hashing for image data with future proof options marks the end of relying upon MD5 checksums when verifying image payloads. OSSN-0075 mitigation lessens the risk of ID re-usability on those very rare cases when a database purge is necessary.

en: Start using reno to manage release notes.
en_GB: Start using Reno to manage release notes.

en: The DEPRECATED Images API v1 does not have a concept of "visibility", and in a "pure" v1 deployment, you would not notice that anything had changed.  Since, however, we hope that there aren't many of those around anymore, here's what you can expect to see if you use the Images API v1 in a "mixed" deployment.
en_GB: The DEPRECATED Images API v1 does not have a concept of "visibility", and in a "pure" v1 deployment, you would not notice that anything had changed.  Since, however, we hope that there aren't many of those around any more, here's what you can expect to see if you use the Images API v1 in a "mixed" deployment.

en: The Glance documentation section `Running Glance in HTTPD`_ outlines some approaches to use (and not to use) Glance with the Apache httpd server. This is the way Glance is configured as a WSGI application in devstack, so it's the method with which we've had the most experience.  If you try deploying Glance using a different web server, please consider contributing your findings to the Glance documentation.
en_GB: The Glance documentation section `Running Glance in HTTPD`_ outlines some approaches to use (and not to use) Glance with the Apache HTTPd server. This is the way Glance is configured as a WSGI application in devstack, so it's the method with which we've had the most experience.  If you try deploying Glance using a different web server, please consider contributing your findings to the Glance documentation.

en: The Glance policies have been modified to drop the system scope. Every API policy is scoped to project. This means that system scoped users will get 403 permission denied error.
en_GB: The Glance policies have been modified to drop the system scope. Every API policy is scoped to the project. This means that system-scoped users will get a 403 permission denied error.

en: The Image ``checksum`` property contains an MD5 hash of the image data associated with an image.  MD5 has not been considered secure for some time, and in order to comply with various security standards (for example, FIPS), an implementation of the MD5 algorithm may not be available on glance nodes.
en_GB: The Image ``checksum`` property contains an MD5 hash of the image data associated with an image.  MD5 has not been considered secure for some time, and in order to comply with various security standards (for example, FIPS), an implementation of the MD5 algorithm may not be available on Glance nodes.

en: The Image service API call ``DELETE /v2/cache/{image_id}`` and ``DELETE /v2/cache`` now returns a 204 (No Content) response code to indicate success. In glance 24.0.0 (the initial Yoga release), it had mistakenly returned a 200.
en_GB: The Image service API call ``DELETE /v2/cache/{image_id}`` and ``DELETE /v2/cache`` now returns a 204 (No Content) response code to indicate success. In Glance 24.0.0 (the initial Yoga release), it had mistakenly returned a 200.

en: The Xena release of Glance is a midpoint in the process of refactoring how our policies are applied to API operations. The goal of applying policy enforcement in the API will ultimately increase the flexibility operators have over which users can do what operations to which images, and provides a path for compliant Secure RBAC and scoped tokens. In Xena, some policies are more flexible than they once were, allowing for more fine-grained assignment of responsibilities, but not all things are possible yet. If `enforce_secure_rbac` is not enabled, most things are still enforcing the legacy behavior of hard and fast admin-or-owner requirements.
en_GB: The Xena release of Glance is a midpoint in the process of refactoring how our policies are applied to API operations. The goal of applying policy enforcement in the API will ultimately increase the flexibility operators have over which users can do what operations to which images, and provides a path for compliant Secure RBAC and scoped tokens. In Xena, some policies are more flexible than they once were, allowing for more fine-grained assignment of responsibilities, but not all things are possible yet. If `enforce_secure_rbac` is not enabled, most things are still enforcing the legacy behaviour of hard and fast admin-or-owner requirements.

en: The ``web-download`` import-method, intended to be a replacement for the popular Image Service API v1 "copy-from" functionality, is configurable so that you can avoid the vulnerabilty described in `OSSN-0078`_.  See the Interoperable Image Import section of the `Glance Administration Guide`_ for details.
en_GB: The ``web-download`` import-method, intended to be a replacement for the popular Image Service API v1 "copy-from" functionality, is configurable so that you can avoid the vulnerability described in `OSSN-0078`_.  See the Interoperable Image Import section of the `Glance Administration Guide`_ for details.

en: The `documentation was reorganized`_ in accord with the new standard layout for OpenStack projects.
en_GB: The `documentation was reorganised`_ in accord with the new standard layout for OpenStack projects.

en: The ability to update an image to have 'community' visibility is governed by a policy target named 'communitize_image'.  The default is empty, that is, any user may communitize an image.
en_GB: The ability to update an image to have 'community' visibility is governed by a policy target named 'communitize_image'.  The default is empty, that is, any user may communitise an image.

en: The cinder store lazy migration code assumed that the user performing the GET was authorized to modify the image in order to perform the update. This will not be the case for shared or public images where the user is not the owner or an admin, and would result in a 404 to the user if a migration is needed but not completed. Now, we delay the migration if we are not sufficiently authorized, allowing the first GET by the owner (or an admin) to perform it. See Bug 1932337_ for more information.
en_GB: The Cinder store lazy migration code assumed that the user performing the GET was authorised to modify the image in order to perform the update. This will not be the case for shared or public images where the user is not the owner or an admin, and would result in a 404 to the user if a migration is needed but not completed. Now, we delay the migration if we are not sufficiently authorised, allowing the first GET by the owner (or an admin) to perform it. See Bug 1932337_ for more information.

en: The default value for the API configuration option ``workers`` was previously the number of CPUs available.  It has been changed to be the min of {number of CPUs, 8}.  Any value set for that option, of course, is honored.  See Bug 1748916_ for details.
en_GB: The default value for the API configuration option ``workers`` was previously the number of CPUs available.  It has been changed to be the min of {number of CPUs, 8}.  Any value set for that option, of course, is honoured.  See Bug 1748916_ for details.

en: The default value of ``[oslo_policy] policy_file`` config option has been changed from ``policy.json`` to ``policy.yaml``. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the `oslopolicy-convert-json-to-yaml <https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html>`_ tool to convert a JSON to YAML formatted policy file in backward compatible way.
en_GB: The default value of ``[oslo_policy] policy_file`` config option has been changed from ``policy.json`` to ``policy.yaml``. Operators who are utilizing customised or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the `oslopolicy-convert-json-to-yaml <https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html>`_ tool to convert a JSON to YAML formatted policy file in backward compatible way.

en: 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.
en_GB: 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.

en: The image-create operation allows a visibility to be set at the time of image creation.  This option was probably not used much given that previously there were only two visibility values available, one of which ('public') is by default unassignable by end users.  Operators may wish to update their documentation or tooling to specify a visibility value when end users create images.  To summarize:
en_GB: The image-create operation allows a visibility to be set at the time of image creation.  This option was probably not used much given that previously there were only two visibility values available, one of which ('public') is by default unassignable by end users.  Operators may wish to update their documentation or tooling to specify a visibility value when end users create images.  To summarise:

en: The lock_path config option from oslo.concurrency is now required for using the sql image_cache driver. If one is not specified it will default to the image_cache_dir and emit a warning.
en_GB: The lock_path config option from oslo.concurrency is now required for using the SQL image_cache driver. If one is not specified it will default to the image_cache_dir and emit a warning.

en: The policies protecting the image API have been deprecated in favor of more consistent defaults that use the `member` and `reader` default roles from keystone. If your deployment relies on overriding the default policies, please review the new defaults and how they may impact your deployment.
en_GB: The policies protecting the image API have been deprecated in favour of more consistent defaults that use the `member` and `reader` default roles from Keystone. If your deployment relies on overriding the default policies, please review the new defaults and how they may impact your deployment.

en: The policy check that we ran when an image is not found is removed. This previously allowed an operator to override the behavior of a 404 to be a 403, in contrast to the API documentation and design goals of defaulting to 404 for information-hiding reasons. This check is no longer run in the case of a NotFound result from the database, so any policy attempting to control that behavior will be ignored from now on.
en_GB: The policy check that we ran when an image is not found is removed. This previously allowed an operator to override the behavior of a 404 to be a 403, in contrast to the API documentation and design goals of defaulting to 404 for information-hiding reasons. This check is no longer run in the case of a NotFound result from the database, so any policy attempting to control that behaviour will be ignored from now on.

en: The secure "multihash" image properties, ``os_hash_algo`` and ``os_hash_value`` have been available on images since glance version 17.0.0 (Rocky).  Until this point, the MD5 ``checksum`` property has been populated solely for backward compatability.  It is not, however, necessary for validating downloaded image data.
en_GB: The secure "multihash" image properties, ``os_hash_algo`` and ``os_hash_value`` have been available on images since glance version 17.0.0 (Rocky).  Until this point, the MD5 ``checksum`` property has been populated solely for backward compatibility.  It is not, however, necessary for validating downloaded image data.

en: The ssl support from Glance has been removed as it worked only under PY27 which is not anymore supported environment. Termination of encrypted connections needs to happen externally as soon as move to PY3 happens. Any deployment needing end to end encryption would need to put either reverse proxy (using fully blown http server like Apache or Nginx will cause significant performance hit and we advice using something more simple that does not break the http protocol) in front of the service or utilize ssl tunneling (like stunnel) between loadbalancers and glance-api.
en_GB: The SSL support from Glance has been removed as it worked only under PY27 which is not any more supported environment. Termination of encrypted connections needs to happen externally as soon as move to PY3 happens. Any deployment needing end to end encryption would need to put either reverse proxy (using fully blown http server like Apache or Nginx will cause significant performance hit and we advice using something more simple that does not break the http protocol) in front of the service or utilize SSL tunnelling (like stunnel) between loadbalancers and glance-api.

en: The unused `modify_task` policy has been deprecated for removal. It was never honored or checked as part of an API operation. As a result, it has been deprecated for removal since overriding it has no direct impact on the tasks API, which remains a deprecated, admin-only API.
en_GB: The unused `modify_task` policy has been deprecated for removal. It was never honoured or checked as part of an API operation. As a result, it has been deprecated for removal since overriding it has no direct impact on the tasks API, which remains a deprecated, admin-only API.

en: This release brings expansion in the  functionality of stores-detail API. The stores detail API will list the way each store is configured, whereas previously this worked only for rbd store. The API remains admin-only by default as it exposes backend information.
en_GB: This release brings expansion in the functionality of stores-detail API. The store's detail API will list the way each store is configured, whereas previously this worked only for the RBD store. The API remains admin-only by default as it exposes backend information.

en: This release has impact on API behavior.
en_GB: This release has impact on API behaviour.

en: This release introduces new APIs for cache related operations. This new version of the cache API will help administrators to cache images on dedicated glance nodes as well. For more information, see the ``Cache Manage`` section in the `api-ref-guide <https://developer.openstack.org/api-ref/image/v2/index.html#cache-manage>`_.
en_GB: This release introduces new APIs for cache related operations. This new version of the cache API will help administrators to cache images on dedicated Glance nodes as well. For more information, see the ``Cache Manage`` section in the `api-ref-guide <https://developer.openstack.org/api-ref/image/v2/index.html#cache-manage>`_.

en: 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.
en_GB: 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.

en: We have tried to minimize the impact upon end users, but want to point out some issues to be aware of.
en_GB: We have tried to minimise the impact upon end users, but want to point out some issues to be aware of.

en: We recommend to enable the both scope as well new defaults together otherwise you may experience some late failures with unclear error messages.
en_GB: We recommend enabling both scopes as well new defaults together otherwise you may experience some late failures with unclear error messages.

en: What this option does is to grant complete admin access to any authenticated user with a particular role.  *This overrides any policy rules configured in the policy configuration file.*  While everything will behave as expected if you are also using the default policy settings, this setting may cause anomalous behavior when you are configuring custom policies.
en_GB: What this option does is to grant complete admin access to any authenticated user with a particular role.  *This overrides any policy rules configured in the policy configuration file.*  While everything will behave as expected if you are also using the default policy settings, this setting may cause anomalous behaviour when you are configuring custom policies.

en: While fixing race condition issue during victoria we started updating 'message' property of the task which helps calculate time based on last updated time of task to burst the lock as well as show how much data has been copied of that image. As glance task API's are restricted from use by normal users we are adding new API /v2/images/{image_id}/tasks which will return all tasks associated with that image. In addition to task information this API will also return `request-id` and `user-id` to help users in debugging.
en_GB: While fixing race condition issue during Victoria we started updating 'message' property of the task which helps calculate time based on last updated time of task to burst the lock as well as show how much data has been copied of that image. As glance task API's are restricted from use by normal users we are adding new API /v2/images/{image_id}/tasks which will return all tasks associated with that image. In addition to task information this API will also return `request-id` and `user-id` to help users in debugging.

en: ``all_stores_must_succeed``: Control wether the import have to succeed in all stores.
en_GB: ``all_stores_must_succeed``: Control whether the import have to succeed in all stores.

en: ``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.
en_GB: ``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.

en: bug 1570789: Metadefs API returns 500 error when 4 byte unicode character is passed
en_GB: bug 1570789: Metadefs API returns 500 error when 4 byte Unicode character is passed

en: bug 1582304: Allow tests to run when http proxy is set
en_GB: bug 1582304: Allow tests to run when HTTP proxy is set

en: bug 1609571: version negotiation api middleware was NOT up to date to include v2.3
en_GB: bug 1609571: version negotiation API middleware was NOT up to date to include v2.3

en: bug 1612341: Add cpu thread pinning flavor metadef
en_GB: bug 1612341: Add CPU thread pinning flavour metadef
