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