[Openstack-operators] need feedback about Glance image 'visibility' migration in Ocata

Brian Rosmaita brian.rosmaita at RACKSPACE.COM
Thu Nov 17 04:49:01 UTC 2016


Hello Operators,

The long-awaited implementation of "community images" in Glance [0] is
just around the corner, but before we can merge it, we need to make a
decision about how the database migration of the image 'visibility' field
will work.  We could use your help.

Here's what's at issue:

Up through the Newton release of the Images API v2, there are two values
for 'visibility':
* public
* private

As you're aware, an end user can "share" an image by adding members to it.
 Currently, this does not change the visibility of the image: it remains
'private' even though other users have access to it, which is kind of
counterintuitive.  As part of the community images implementation in
Ocata, the range of values for 'visibility' is changed to:
* public
* private
* shared
* community

In Newton, an image had to have 'private' visibility in order for member
operations to be performed on it.  In Ocata, this is being changed so that
an image must have 'shared' visibility in order to be subject to member
operations.  Now, there's a bit of weirdness here in that an image with
'shared' visibility that doesn't have any members on it is not actually
accessible to anyone, and hence maybe not "shared"; but I think a better
way to look at it is that any image with 'shared' visibility is in fact
shared with all the image members it has (which could be zero).
(Editorial comment: I think this is a definite improvement over images
with 'private' visibility that aren't actually private.)

So what's the problem?  Well, our original proposal was that an image
would have a default visibility of 'private'.  Some concerned users
brought to our attention that this would introduce a backward
incompatibility into the image sharing workflow:

Diablo to Newton workflow: (1) create an image with default visibility,
(2) share it by adding members

Ocata workflow:  (1) create an image with default visibility, (2) change
its visibility to 'shared', (3) add image members

During development, we realized that if the default visibility were
'shared', then everything would behave as it does now.  If an end user
didn't add any members, the image would effectively be "private" since no
one other than the owner would have access to it; and if a user wanted to
add members, they could be immediately added just as they are in the
Diablo-to-Newton workflow.

Further, given that there are OpenStack clouds using both the Image v1 and
v2 APIs, we need to look at the situation with respect to v1 (which was
deprecated in Newton, but is still supported in Ocata).  The v1 API
doesn't have any concept of 'visibility'; all it has is the boolean
'is_public'.  If an image is "born" with 'shared' visibility in the
database, is_public will be False in the v1 API, as it is now, and
further, the image can be shared immediately via the v1 API, as it can
now.  So this change is backward compatible for v1.  At the same time, the
visibility rules for the v2 API can be respected if a user manipulates the
same image using the v2 API.  End users who solely use the v1 API can be
blissfully unaware that an image's visibility is "really" 'shared', but
this will be appropriately visible to users of the v2 API.

What if a v2 user sets the visibility of an image to 'private'?  If some
other user in that project tries to share that image via the v1 API, the
v1 user will get a 409 (Conflict) response.  This seems appropriate,
because by changing the visibility to 'private', the v2 user explicitly
put the image in a state where it cannot be shared, and we don't want
someone to do an end-run around that simply by using the v1 API.  Is this
a problem for v1 users?  I'd argue it's not.  If the users in a project
*only* use v1, this issue will never arise.  It can only occur if some
user in the project is using the v2 API, and in that case, that user will
have the ability to change the image's visibility back to 'shared' if
sharing really is desired.

Thus, a default visibility of 'shared' will work well for mixed v1/v2
deployments.

Note that we're just talking about the default value for 'visibility'; if
an end user specifies a particular visibility as part of the image-create
request, it will be honored (assuming the user has appropriate permissions
to create an image with that visibility).  The key point here is that even
though the default visibility *value* will be different than it was up
through Newton, the default visibility *behavior* in Ocata will be
identical.  We think this will make for an easy transition for users.

Sounds great, so what's the problem?  Well, as part of the upgrade to
Glance Ocata, the database will have to be migrated so that all images
have a specific visibility.  (What's really in the database up through
Newton, believe it or not, is the boolean 'is_public'.)  All images with
is_public == True will be migrated to visibility == 'public'.  Prior to
Ocata, community images don't exist, so no images will be migrated to
visibility == 'community'.  But what to do about the images in the
database with is_public == False?

If you've read this far, you probably see where we're going with this: it
makes sense that all these images get visibility set to 'shared'. As
discussed above, current images with no members will be effectively
private (so no data leakage), while images with members will have the
appropriate visibility.  Functionally and behaviorally, this will
introduce no difference from pre-Ocata Glance.  To summarize, the
advantages are:

* Images with no members will be ready for sharing, just as they are now.
* Users won't have to change their workflow to share images.
* Pre-Ocata images with the default visibility will still have the default
visibility (only the identifier expressing this will be different).
* The result of the migration is consistent with the Ocata default
visibility for images.

(What I mean by the last point is best illustrated by considering an
alternative migration strategy, in which the images with is_public ==
False are given different visibilities: 'private' if the image has no
members, and 'shared' if the image has at least one member.  This leads to
an inconsistency in how images can be shared: new images created with
default visibility *after* the migration can have members added
immediately, whereas images that existed *before* the migration must first
be updated to visibility == 'shared' before members can be added.  This is
an inconsistency in behavior that's likely to confuse users.)

The disadvantage to migrating all is_public == False to visibility ==
'shared' is:
* images that formerly had visibility == 'private' will show with
visibility == 'shared', and this may cause panic among some users (and
hence, support calls)

So, finally, here's the question we need help with: as an OpenStack
operator, which image visibility migration strategy do you prefer?

(A) All Diablo-to-Newton 'private' images are migrated to 'shared'.
Pros: workflow for image sharing stays the same as it is now
Cons: possible calls to support from users concerned that their images now
have visibility == 'shared'

(B) 'private' images with no members stay 'private', 'private' images with
members are migrated to 'shared'.
Pros: users won't worry that images they haven't shared are showing as
having visibility == 'shared'
Cons: possible calls to support from users getting 409s when they try to
share some images 

Our current proposal [1] is to use strategy (A), but we want this to be a
data-informed decision.  Please use this one-question Google form to
record your response (even if you have no preference--it's still a data
point for the Glance team):

https://goo.gl/forms/oH0C9uY64A5oBZXW2

Please respond right now ... the form contains only a single
multiple-choice question.

Thank you for your help!
brian

[0] 
http://specs.openstack.org/openstack/glance-specs/specs/newton/approved/gla
nce/community_visibility.html
[1] https://review.openstack.org/#/c/396919/




More information about the OpenStack-operators mailing list