Open Stack

Something has come up with a tempest test for Glance and the community
images implementation, and I think it could use some mailing list
discussion, as everyone might not be aware of the patch where the
discussion is happening now [1].

First, the Glance background, to get everyone on the same page:

As part of implementing community images [2], the 'visibility' field of
an image is going from being 2-valued to being 4-valued.  Up to now, the
only values have been 'private' and 'public', which meant that shared
images were 'private', which was inaccurate and confusing (and bugs were
filed with Glance about shared images not having visibility 'shared'
[3a,b]).

With the new visibility enum, the Images API v2 will behave as follows:

* An image with visibility == 'private' is not shared, and is not
shareable until its visibility is changed to 'shared'.

* An image must have visibility == 'shared' in order to do member
operations or be accessible to image members.

* The default visibility of a freshly-created image is 'shared'.  This
may seem weird, but a freshly-created image has no members, so it's
effectively private, behaving exactly as a freshly-created image does,
pre-Ocata.  It's also ready to immediately accept a member-create call,
as freshly-created images are pre-Ocata.  So from a workflow
perspective, this change is backward compatible.

* After much discussion [4], including discussion with operators and an
operator's survey [5], we decided that the correct migration of
'visibility' values for existing images when a cloud is updated would
be: public images stay 'public', private images with members become
'shared', and private images without images stay 'private'.  (Thus, if
you have a 'private' image, you'll have to change it to 'shared' before
you can add members.  On the other hand, now it's *really* private.)

* You can specify a visibility at the time of image-creation, as you can
now.  But if you specify 'private', what you get is *really* private.
This either introduces a minor backward incompatibility, or it fixes a
bug, depending on how you look at it.  The key thing is, if you *don't*
specify a visibility, an image with the default visibility will behave
exactly as it does now, from the perspective of being able to make API
calls on it (e.g., adding members).

Thanks for reading this far.  (There's a much more detailed discussion
in the spec; see the "Other end user impact" section. [2])  Here's the
point of this email:

The community images patch [6] is causing a recently added tempest test
[7] to fail.  The test in question uses an image that was created by a
request that explicitly specified visibility == private.  Eventually it
tries to add a member to this image, and as discussed above, this
operation will fail once we have merged Community Images (because the
image visibility is not 'shared').  If the image had been created with
the default visibility (that is, not explicitly specifying a visibility
in the image-create call), this problem would not arise.  Keep in mind
that prior to Ocata, there was no reason for end users to specify an
image visibility explicitly upon image creation because there were only
two possible values, one of which required special permissions in order
to use successfully.  Thus, we feel that the situation occurring in the
test is not one that many end users will come across.  We have discussed
the situation extensively with the broader OpenStack community, and the
consensus is that this change to the API is acceptable.

To conclude: before and after this change, the "default" visibility of
an image will allow adding members to the image. We would hope that the
failing tempest test could be revised to not explicitly request
"private" visibility but to allow Glance to use its default visibility
instead [10]. We have wide cross-project support [8, 9] for the
"Community Images" work and the only thing blocking us now is tempest.
Due to the shortened cycle in Ocata, we'd really appreciate finding
common ground with the QA team quickly.

thanks,
brian

[1] https://review.openstack.org/#/c/412731/
[2]
http://specs.openstack.org/openstack/glance-specs/specs/newton/approved/glance/community_visibility.html
[3a] https://bugs.launchpad.net/glance/+bug/1394299
[3b] https://bugs.launchpad.net/glance/+bug/1452443
[4] https://review.openstack.org/#/c/396919/
[5]
http://lists.openstack.org/pipermail/openstack-operators/2016-November/012107.html
[6] https://review.openstack.org/#/c/369110/
[7] https://review.openstack.org/#/c/317088/
[8]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107349.html
[9]
http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-06-09-15.59.log.html#l-84
[10] https://review.openstack.org/#/c/414261