Pike Series Release Notes

15.0.1

Prelude

This point release contains minor changes to keep the Pike release of Glance stable with respect to current operating system packages.

Bug Fixes

  • Changes in Python 2.7 distribution packages affected Glance’s use of eventlet. As a result, the team backported a fix from eventlet 0.22.0 to the Glance code. (The Pike release of OpenStack uses eventlet 0.20.0.) See Bug 1747304 for details.

15.0.0

Prelude

  • The minor version of the Images API v2 is bumped to 2.6 to introduce an EXPERIMENTAL version of the API that includes the new calls introduced for the Minimal Viable Product delivery of the refactored image import functionality. Version 2.5 remains the CURRENT version of the Images API.

New Features

  • The image-list call to the Images v2 API now recognizes a protected query-string parameter. This parameter accepts only two values: either true or false. The filter is case-sensitive. Any other value will result in a 400 response to the request. See the protected filter specification document for details.

  • A new policy, tasks_api_access has been introduced so that ordinary user credentials may be used by Glance to manage the tasks that accomplish the interoperable image import process without requiring that operators expose the Tasks API to end users.

  • Glance is now packaged with a WSGI script entrypoint, enabling it to be run as a WSGI application hosted by a performant web server. See Running Glance in HTTPD in the Glance documentation for details.

    There are some limitations with this method of deploying Glance and we do not recommend its use in production environments at this time. See the Known Issues section of this document for more information.

Known Issues

  • Although support has been added for Glance to be run as a WSGI application hosted by a web server, the atypical nature of the Images APIs provided by Glance, which enable transfer of copious amounts of image data, makes it difficult for this approach to work without careful configuration. Glance relies on the use of chunked transfer encoding for image uploads, and the support of chunked transfer encoding is not required by the WSGI specification.

    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.

    Currently, we are experiencing some problems in the gate when Glance is configured to run in devstack following the guidelines recommended in the documentation. You can follow Bug 1703856 to learn more.

    As far as the Glance team can determine, the difficulties running Glance as a WSGI application are caused by issues external to Glance. Thus the Glance team recommends that Glance be run in its normal standalone configuration, particularly in production environments. If you choose to run Glance as a WSGI application in a web server, be sure to test your installation carefully with realistic usage scenarios.

Upgrade Notes

  • An EXPERIMENTAL version of the Images API supplied by Glance is introduced as 2.6. It includes the new API calls introduced for the refactored image import functionality. This functionality is not enabled by default, so the CURRENT version of the Images API remains at 2.5. There are no changes to the version 2.5 API in this release, so all version 2.5 calls will work whether or not the new import functionality is enabled or not.

    The version 2.6 API is being introduced as EXPERIMENTAL because it is a Minimal Viable Product delivery of the functionality described in the refactored image import specification. As an MVP, the responses described in that specification are abbreviated in version 2.6. It is expected that version 2.6 will be completed in Queens, but at this time, we encourage operators to try out the new functionality, but keep in mind its EXPERIMENTAL nature.

  • Deprecated values are no longer recognized for the configuration option store_type_preference. The two non-standard values ‘filesystem’ and ‘vmware_datastore’ were DEPRECATED in Newton and are no longer operable. The correct values for those stores are ‘file’ and ‘vmware’. See the Newton release notes for more information at https://docs.openstack.org/releasenotes/glance/newton.html#upgrade-notes

  • Code for the OpenStack Artifacts Service (Glare) and its EXPERIMENTAL API has been removed from the Glance codebase, as it was relocated into an independent Glare project repository during a previous release cycle. The database upgrade for the Glance Pike release drops the Glare tables (named ‘artifacts’ and ‘artifact_*’) from the Glance database.

    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.

  • 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.

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

    • The property img_hide_hypervisor_id has been added to the namespace OS::Compute::LibvirtImage.

    • Several new values were added for the vmware_ostype property in the OS::Compute::VMware namespace.

    You may upgrade these definitions using:

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

  • You may set the timeout option in the keystone_authtoken group in the glance-api.conf file.

  • If you wish to enable the EXPERIMENTAL version 2.6 API that contains the new interoperable image import functionality, set the configuration option enable_image_import to True in the glance-api.conf file. The default value for this option is False.

    The interoperable image import functionality uses the Glance tasks engine. This is transparent to end users, as they do not use the Tasks API for the interoperable image import workflow. The operator, however, must make sure that the following configuration options are set correctly.

    • enable_image_import

    • node_staging_uri

    • the options in the [task] group

    • the options in the [taskflow_executor] group

    See the documentation in the sample glance-api.conf file for more information.

    Additionally, you will need to verify that the task-related policies in the Glance policy.json file are set correctly. These settings are described below.

  • A new policy, tasks_api_access has been introduced so that ordinary user credentials may be used by Glance to manage the tasks that accomplish the interoperable image import process without requiring that operators expose the Tasks API to end users.

    The Tasks API was made admin-only by default in Mitaka by restricting the following policy targets to role:admin: get_task, get_tasks, add_task, and modify_task.

    The new tasks_api_access policy target directly controls access to the Tasks API, whereas targets just mentioned indirectly affect what can be manipulated via the API by controlling what operations can be performed on Glance’s internal task objects. The key point is that if you want to expose the new interoperable image import process to end users while keeping the Tasks API admin-only, you can accomplish this by using the following settings:

    "get_task": "",
"get_tasks": "",
"add_task": "",
"modify_task": "",
"tasks_api_access": "role:admin",

    To summarize: end users do not need access to the Tasks API in order to use the new interoperable image import process. They do, however, need permission to access internal Glance task objects.

    We recommend that all operators adopt the policy settings just described independently of the decision whether to expose the EXPERIMENTAL version 2.6 API.

Security Issues

  • A new policy, tasks_api_access has been introduced so that ordinary user credentials may be used by Glance to manage the tasks that accomplish the interoperable image import process without requiring that operators expose the Tasks API to end users.

    This is a good time to review your Glance policy.json file to make sure that if it contains a default target, the rule is fairly restrictive (“role:admin” or “!” are good choices). The default target is used when the policy engine cannot find the target it’s looking for. This can happen when a new policy is introduced but the policy file in use is from a prior release.

Bug Fixes

  • There was a bug in the experimental zero-downtime database upgrade path introduced in the Ocata release that prevented the experimental upgrade from working. This has been fixed in the Pike release. The bug did not affect the the normal database upgrade operation.

  • The following are some highlights of the bug fixes included in this release.

    • Bug 1655727: Invoke monkey_patching early enough for eventlet 0.20.1

    • Bug 1657459: Fix incompatibilities with WebOb 1.7

    • Bug 1554412: Provide user friendly message for FK failure

    • Bug 1664709: Do not serve partial image download requests from cache

    • Bug 1482129: Remove duplicate key from dictionary

    • Bug 1229823: Handle file delete races in image cache

    • Bug 1686488: Fix glance image-download error

    • Bug 1516706: Prevent v1_api from making requests to v2_registry

    • Bug 1701346: Fix trust auth mechanism

  • Glance had been accepting the Content-Range header for GET v2/images/{image_id}/file requests, contrary to RFC 7233. Following RFC 7233, Glance will now:

    • Accept the Range header in requests to serve partial images.

    • Include a Content-Range header upon successful delivery of the requested partial content.

    Please note that not all Glance storage backends support partial downloads. A Range request to a Glance server with such a backend will result in the entire image content being delivered despite the 206 response code.

  • Please note a change in the Scrubber’s behaviour in case of job fetching errors:

    • If configured to work in daemon mode, the Scrubber will log an error message at level critical, but will not exit the process.

    • If configured to work in non-daemon mode, the Scrubber will log an error message at level critical and exit with status one.

Other Notes

  • Code for the OpenStack Artifacts Service (Glare) and its EXPERIMENTAL API has been removed from the Glance codebase.

    The Artifacts API was an EXPERIMENTAL API that ran on the Glance service endpoint as /v3 in the Liberty release. In the Mitaka release, the Glance /v3 EXPERIMENTAL API was deprecated and the Artifacts Service ran on its own endpoint (completely independent from the Glance service endpoint) as an EXPERIMENTAL API, versioned as v0.1. In both the Liberty and Mitaka releases, Glare ran on code stored in the Glance code repository and used its own tables in the Glance database.

    In the Newton release, the Glare code was relocated into its own Glare project repository. Also in the Newton release, Glare ran an EXPERIMENTAL Artifacts API versioned as v1.0 on its own endpoint and used its own database.

    For the Pike release, the legacy Glare code has been removed from the Glance code repository and the legacy ‘artifacts’ and ‘artifact_*’ database tables are dropped from the Glance database. As the Artifacts service API was an EXPERIMENTAL API in Glance and has not used the Glance database since Mitaka, no provision is made for migrating data from the Glance database to the Glare database.

  • The Image Service API Reference has been updated with a section on the Interoperable image import process (also known as “image import refactored”) and the API calls that are exposed to implement it in the EXPERIMENTAL v2.6 of the API.