Ocata Series Release Notes

14.0.1

Prelude

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

Corrections de bugs

• 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 Ocata release of OpenStack uses eventlet 0.19.0.) See Bug 1747305 for details.

Other Notes

• Translations have been updated.

14.0.0

Prelude

• Add ploop to the list of supported disk formats.

• Experimental zero-downtime database upgrade using an expand-migrate-contract series of operations is available.

• The minor version of the Images API v2 is bumped to 2.5.

• The Community Images feature has been introduced in the Images API v2. This enables a user to make an image available for consumption by all other users. In association with this change, the “visibility” values for an image have been expanded to include “community” and “shared”.

Location updates for images are now restricted to images in active or queued status. Please refer to the « Bug Fixes » section for more information.

Nouvelles fonctionnalités

• The identifier ploop has been added to the list of supported disk formats in Glance. The respective configuration option has been updated and the default list shows ploop as a supported format.

• Image “visibility” changes.

  • Prior to Ocata, an image with “private” visibility could become shared by adding members to it, though its visibility remained “private”. In order to make the visibility of images more clear, in Ocata the following changes are introduced:

    • A new value for visibility, “shared”, is introduced. Images that have or can accept members will no longer be displayed as having “private” visibility, reducing confusion among end users.

    • An image must have “shared” visibility in order to accept members. This provides a safeguard from “private” images being shared inadvertently.

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

• Image visibility may be specified at the time of image creation.

  • As mentioned above, the default visibility of an image is “shared”. If a user wants an image to be private and not accept any members, a visibility of “private” can be explicitly assigned at the time of creation.

    • Such an image will require its visibility to be updated to “shared” before it will accept members.

• Image visibility is changed using the image update (PATCH) call.

  • Note: This is not a change. It’s simply mentioned for completeness.

• A new value for the Image “visibility” field, “community”, is introduced.

  • An image with “community” visibility is available for consumption by any user.

  • In order to prevent users spamming other users” image-list response, community images are not included in the image-list response unless specifically requested by a user.

    • For example, GET v2/images?visibility=community

    • 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

Notes de mises à jours

• The disk_format config option enables ploop as supported by default.

• The database migration engine used by Glance for database upgrades has been changed from SQLAlchemy Migrate to Alembic in this release.

  • This has necessitated a change in the location and naming convention for migration scripts. Developers, operators, and DevOps are strongly encouraged to read through the Database Management section of the Glance documentation for details of the changes introduced in the Ocata release. Here’s a brief summary of the changes:

    • All the glance manage db commands are changed appropriately to use Alembic to perform operations such as version, upgrade, sync and version_control. Hence, the « old-style » migration scripts will no longer work with the Ocata glance manage db commands.

    • Database versions are no longer numerical. Instead, they are the revision ID of the last migration applied on the database.

      • For example, the Liberty migration, which was version 42 under the old system, will now appear as liberty. The Mitaka migrations 43 and 44 appear as mitaka01 and mitaka02, respectively.

  • The change in migration engine has been undertaken in order to enable zero-downtime database upgrades, which are part of the effort to implement rolling upgrades for Glance (scheduled for the Pike release).

    • A preview of zero-downtime database upgrades is available in this release, but it is experimental and not supported for production systems. Please consult the Database Management section of the Glance documentation for details.

• The CURRENT version of the version 2 Images API supplied by Glance is now 2.5. Changes include:

  • The “visibility” enumeration has been increased from two values (public, private) to four values (public, private, shared, and community).

  • Formerly, it was possible to add members to an image whose visibility was private, thereby creating a « shared » image. In this release, an image must have a visibility of shared in order to accept member operations. Attempting to add a member to an image with a visibility of private will result in a 4xx response containing an informative message.

• Some backend store names were inconsistent between glance and glance_store. This meant that operators of the VMware datastore or file system store were required to use store names in glance-api.conf that did not correspond to any valid identifier in glance_store. As this situation encouraged misconfiguration and operator unhappiness, we have made the store names consistent in the Newton release. What this means for you:

  • This change applies only to operators who are using multiple image locations

  • This change applies only to operators using the VMware datastore or filesystem stores

  • This change applies only to the store_type_preference option

  • VMware datastore operators: The old name, now DEPRECATED, was vmware_datastore. The new name, used in both glance and glance_store, is vmware

  • File system store operators: the old name, now DEPRECATED, was filesystem. The new name, used in both glance and glance_store, is file

  • This change is backward compatible, that is, the old names will be recognized by the code during the deprecation period. Support for the deprecated names will be removed in the Pike release

  • We strongly encourage operators to modify their glance-api.conf files immediately to use the new names

• A new value for the Image “visibility” field, “community”, is introduced.

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

• Visibility migration of current images

  • Prior to Ocata, the Glance database did not have a “visibility” column, but instead used a boolean “is_public” column, which was translated into “public” or “private” visibility in the Images API v2 image response. As part of the upgrade to Ocata, a “visibility” column is introduced into the images table. It will be populated as follows

    • All images currently with “public” visibility (that is, images for which “is_public” is True in the database) will have their visibility set to “public”.

    • Images currently with “private” visibility (that is, images for which “is_public” is False in the database) and that have image members, will have their visibility set to “shared”.

    • Those images currently with “private” visibility (that is, images for which “is_public” is False in the database) and that have no image members, will have their visibility set to “private”.

      • Note that such images will have to have their visibility updated to “shared” before they will accept members.

• Impact of the Ocata visibility changes on end users of the Images API v2

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

    • The migration of image visibility assigns sensible values to images, namely, “private” to images that end users have not assigned members, and “shared” to those images that have members at the time of the upgrade. Previously, if an end user wanted to share a private image, a member could be added directly. After the upgrade, the image will have to have its visibility changed to “shared” before a member can be assigned.

    • The default value of “shared” may seem weird, but it preserves the pre-upgrade workflow of: (1) create an image with default visibility, (2) add members to that image. Further, an image with a visibility of “shared” that has no members is not accessible to other users, so it is functionally a private image.

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

      • “public” - reserved by default for images supplied by the operator for the use of all users

      • “private” - the image is accessible only to its owner

      • “community” - the image is available for consumption by all users

      • “shared” - the image is completely accessible to the owner and available for consumption by any image members

• Impact of the Ocata visibility changes on the Images API v1

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

    • In the v1 API, images have an is_public field (but no visibility field). Images for which is_public is True are the equivalent of images with “public” visibility in the v2 API. Images for which is_public is false are the equivalent of v2 “shared” images if they have members, or the equivalent of v2 “private” images if they have no members.

    • An image that has “community” visibility in the v2 API will have is_public == False in the v1 API. It will behave like a private image, that is, only the owner (or an admin) will have access to the image, and only the owner (or an admin) will see the image in the image-list response.

    • Since the default value for “visibility” upon image creation is “shared”, an image freshly created using the v1 API can have members added to it, just as it did pre-Ocata.

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

      • Use the v2 API to change the visibility of the image to “shared”. Then it will accept members in either the v1 or v2 API.

      • Use the v1 API to update the image so that is_public is False. This will reset the image’s visibility to “shared”, and it will now accept member operations.

      • Note that in either case, when dealing with an image that has “private” visibility in the v2 API, there is a safeguard against a user unintentionally adding a member to an image and exposing data. The safeguard is that you must perform an additional image update operation in either the v1 or v2 API before you can expose it to other users.

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

• The metadata definition for hypervisor_type in the OS::Compute::Hypervisor namespace has been extended to include the Virtuozzo hypervisor, designated as vz. You may upgrade the definition using:

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

Problèmes de sécurités

• All qemu-img info calls are now run under resource limitations that limit the CPU time and address space usage of the process running the command to 2 seconds and 1 GB respectively. This addresses the bug https://bugs.launchpad.net/glance/+bug/1449062 Current usage of « qemu-img » is limited to Glance tasks, which by default (since the Mitaka release) are only available to admin users. We continue to recommend that tasks only be exposed to trusted users

Corrections de bugs

• Image location updates to an image which is not in active or queued status can introduce race conditions and security issues and hence a bad experience for users and operators. As a result, we have restricted image location updates in this release. Users will now observe the following:

  • HTTP Response Code 409 (Conflict) will be returned in response to an attempt to remove an image location when the image status is not active

  • HTTP Response Code 409 (Conflict) will be returned in response to an attempt to replace an image location when the image status is not active or queued

Other Notes

• The deprecation path for the configuration option show_multiple_locations has been changed because the mitigation instructions for OSSN-0065 refer to this option. It is now subject to removal on or after the Pike release. The help text for this option has been updated accordingly.