Open Stack

Hello Operators,

As you may be aware, the discussion about image 'visibility' and its
migration carried on into 2017 and was only recently settled.  I'm
writing this because the direction we ultimately took (after much
discussion--did I mention that?) was *not* the recommendation I made in
the email below.  I just want to point that out in case the email below
was last news you'd heard about this issue.

So what actually *did* happen?  There's a patch up for the release note
explaining the visibility changes in Ocata.  As we'd like it to be
completely clear, I'd appreciate it if you'd take a few minutes to read
through it and leave comments on the patch.  Please point out if there's
anything expressed ambiguously, or if there are any questions that come
to mind that aren't addressed in the release notes.

https://review.openstack.org/#/c/422897/

thanks,
brian

On 12/2/16 5:33 PM, Brian Rosmaita wrote:
> 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/
>