Open Stack

- There seems to be no difference between public and community, and the
  README does not do an adequate job of explaining the difference.

- There is nothing conceptually wrong with having something be private
  and letting it have a list of members. Private does not have to mean
  "just one user". I can be a member of a private club for example. That
  does not mean I sit there and drink all alone. Shared seems
  redundant. We can't trust users to manage the members list if they
  really want something to be super-duper-private?

Just my 2 cents and a first impression of these proposed changes. I
don't want to comment in the review until I'm clear on the purpose of
these changes, which at the moment is not clear. Everything that could
be done with these changes can be done now, just with different names.

Brian Rosmaita <rosmaita.fossdev at gmail.com> writes:

> 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/
>> 
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators