Open Stack

On 11/17/16, 7:09 PM, "Sam Morrison" <sorrison at gmail.com<mailto:sorrison at gmail.com>> wrote:

Hi Brian,

I don't think the user can shoot themselves in the foot here. If they are adding a member to an image it is pretty clear it means they want to share it.

Yes I can see the case when you want to disable sharing but I don't think the 'visibility' attribute is the way to do it.

What if you want to share an image with a few people and then prevent the sharing of the image to any other people. Do you then change the visibility to private? Maybe this is what the protected attribute should be for?

The visibility change connected with the community images implementation doesn't have a provision for "locking" the member list on an image.  If you change the visibility to private, the image will be inaccessible to any of the image members.  (The 'protected' attribute is already used to prevent accidental deletion of an image, I don't think we want to overload it.)

Basically I think you're overloading the visibility attribute, in one sense it means you can see the image, but then you're also now making it determine if the image can be shared or not.

Another way to think of it is that the 'visibility' indicates who has access to this image.  If it's private, only my project has access; if it's shared, then all the members on the image have access; if it's community, then all users in the cloud have access.  Since members only make sense on shared images, that's the reason why member operations can only be performed on an image in 'shared' visibility.



Cheers,
Sam

On Fri, Nov 18, 2016 at 12:27 AM, Brian Rosmaita <brian.rosmaita at rackspace.com<mailto:brian.rosmaita at rackspace.com>> 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.


Sam


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161118/f58eb7c7/attachment.html>