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