Open Stack

Hi Alexander,

I read through the artifact spec. Based on my reading it does not fix this
issue at all. [1] Furthermore, I do not understand why the glance
developers are focused on adding features like artifacts or signed images
when there are significant usability problems with glance as it currently
stands. This is echoing Sean Dague's comment that bugs are filed against
glance but never addressed.

[1] See the **Sharing Artifact** section, which indicates that sharing may
only be done between projects and that the tenant owns the image.


On Thu, Jul 3, 2014 at 4:55 AM, Alexander Tivelkov <ativelkov at mirantis.com>
wrote:

> Thanks Scott, that is a nice topic
>
> In theory, I would prefer to have both owner_tenant and owner_user to be
> persisted with an image, and to have a policy rule which allows to specify
> if the users of a tenant have access to images owned by or shared with
> other users of their tenant. But this will require too much changes to the
> current object model, and I am not sure if we need to introduce such
> changes now.
>
> However, this is the approach I would like to use in Artifacts. At least
> the current version of the spec assumes that both these fields to be
> maintained ([0])
>
> [0]
> https://review.openstack.org/#/c/100968/4/specs/juno/artifact-repository.rst
>
> --
> Regards,
> Alexander Tivelkov
>
>
> On Thu, Jul 3, 2014 at 3:44 AM, Scott Devoid <devoid at anl.gov> wrote:
>
>>  Hi folks,
>>
>> Background:
>>
>> Among all services, I think glance is unique in only having a single
>> 'owner' field for each image. Most other services include a 'user_id' and a
>> 'tenant_id' for things that are scoped this way. Glance provides a way to
>> change this behavior by setting "owner_is_tenant" to false, which implies
>> that owner is user_id. This works great: new images are owned by the user
>> that created them.
>>
>> Why do we want this?
>>
>> We would like to make sure that the only person who can delete an image
>> (besides admins) is the person who uploaded said image. This achieves that
>> goal nicely. Images are private to the user, who may share them with other
>> users using the image-member API.
>>
>> However, one problem is that we'd like to allow users to share with
>> entire projects / tenants. Additionally, we have a number of images (~400)
>> migrated over from a different OpenStack deployment, that are owned by the
>> tenant and we would like to make sure that users in that tenant can see
>> those images.
>>
>> Solution?
>>
>> I've implemented a small patch to the "is_image_visible" API call [1]
>> which checks the image.owner and image.members against context.owner and
>> context.tenant. This appears to work well, at least in my testing.
>>
>> I am wondering if this is something folks would like to see integrated?
>> Also for glance developers, if there is a cleaner way to go about solving
>> this problem? [2]
>>
>> ~ Scott
>>
>> [1]
>> https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L209
>> [2] https://review.openstack.org/104377
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140711/b3092d5b/attachment.html>