[Openstack-operators] need feedback about Glance image 'visibility' migration in Ocata
jon at csail.mit.edu
Thu Nov 17 16:03:48 UTC 2016
On Thu, Nov 17, 2016 at 01:27:39PM +0000, Brian Rosmaita wrote:
:On 11/17/16, 1:39 AM, "Sam Morrison" <sorrison at gmail.com<mailto:sorrison at gmail.com>> wrote:
:On 17 Nov. 2016, at 3:49 pm, Brian Rosmaita <brian.rosmaita at RACKSPACE.COM<mailto:brian.rosmaita at RACKSPACE.COM>> wrote:
:Ocata workflow: (1) create an image with default visibility, (2) change
:its visibility to 'shared', (3) add image members
:Unsure why this can't be done in 2 steps, when someone adds an image member to a 'private' image the visibility changes to 'shared' automatically.
:Just seems an extra step for no reason?
:Thanks for asking, Sam, I'm sure others have the same question.
:Here's what we're thinking. We want to avoid "magic" visibility transitions as a side effect of another action, and we want all means of changing visibility to be consistent going forward. The two-step 1-1 sharing that automatically takes you from 'private' -> 'shared' is dangerous, as it can expose data and doesn't give an end user a way to make an image "really" private. It's true that all an end user has to do under the new scheme is make one extra API call and then still shoot him/herself in the foot, but at least the end user has to remove the safety first by explicitly changing the visibility of the image from 'private' to 'shared' before the member-list has any effect.
:So basically, the reasons for the extra step are consistency and clarity.
The default 'shared' and migrate to 'shared' proposal make a lot of
sense to me as it keeps 99.99% of the functionality identical and the
one edge case described has prooper behaviour if a but opaque error
and is enduser solvable.
While having both 'private' and 'shared' images probably isn't a
distinction we'd use here, I can see the point. It's like 'locking'
an instance, prevents accidental changes you don't want but is easily
switch off if you change your mind. Presumably writing some clever
policy can even limit the number of people who could change from
'locked' to 'unlocked' in nova or 'private' to 'shared' in glance.
More information about the OpenStack-operators