Open Stack

Hello Operators,

Here are the results of the recent operators' poll concerning the
upcoming image visibility changes in Glance and the direction we plan to
take.  Thanks to all participants for helping us come to a data-driven
decision on a contentious issue.

(For background on the operators' poll, see [0].)

The operators' poll was taken to determine the migration strategy:
(A) All pre-Ocata 'private' images are migrated to 'shared'.
(B) 'private' images with no members stay 'private', 'private' images
with members are migrated to 'shared'.
(C) No strong preference as long as the documentation is clear.

The results were inconclusive:
9 total responses: 4 for (A), 4 for (B), 1 for (C)

I recommend that we go with option (A).  Here's why (in addition to the
arguments made in [2], and my arguments in the "outside" comments on [2]):

(1) There was a comment on the poll that 'private' creates an
expectation that we should meet.  This is basically my reason for
rejecting Hemanth's otherwise sensible comment on the patch that we
should remove 'shared' visibility from Timothy's patch [1] and deal with
the issue later.  This is a problem we should deal with now.

(2) We want to respect the principle of least surprise for users, in
other words, changes in API behavior as a consequence of changes
introduced in Timothy's community/shared images patch [1] are OK if
they're a result of something a user *does*, but not OK if they are
something that *happens to* a user.  To make this point concrete: if a
current image with no members is made 'private' during migration,
suddenly the add-member call can't be made on that image in either the
v1 or v2 API.  If the image is migrated to 'shared', on the other hand,
the current user workflow is not changed.  If the user decides to set
the visibility on the image to 'private', then the add-member calls will
return 409s, but that's OK because it's a result of an action the user took.

But, you say, all my previously 'private' images being listed as
'shared' could be a big surprise!  I think this is a trade-off we should
accept, and address by educating Ocata operators and users of what to
expect.  Here's the key thing people need to be aware of:

You can specify a visibility of 'private' at the time of image creation,
and it's respected.  An interface could (should?) make this choice clear
at the time of image creation.

So to be completely clear, my recommendation is that we go with
migration strategy (A) (i.e., the one specified in [2]) and Timothy's
current community/shared images patch [1].

What's missing in Glance is an easy way to list images that have
visibility 'shared' and no members (and hence, aren't consumable by
anyone other than the owner) from images with visibility 'shared' that
do have members.  This could be addressed by adding a 'has_members'
field to the Image object.  We could use some feedback on how useful
such a field would be.

This course of action is a compromise so that we can preserve backward
compatibility in the Image APIs.  Common to many compromises, no one is
going to be completely happy with the outcome.  But I really think it's
the best way to go.

thanks,
brian


[0]
http://lists.openstack.org/pipermail/openstack-operators/2016-November/012107.html
[1] https://review.openstack.org/#/c/369110/
[2] https://review.openstack.org/#/c/396919/