<div dir="ltr">Hi Alexander,<div><br></div><div>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.</div>
<div><br></div><div>[1] See the **Sharing Artifact** section, which indicates that sharing may only be done between projects and that the tenant owns the image.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jul 3, 2014 at 4:55 AM, Alexander Tivelkov <span dir="ltr"><<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks Scott, that is a nice topic</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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])</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[0] <a href="https://review.openstack.org/#/c/100968/4/specs/juno/artifact-repository.rst" target="_blank">https://review.openstack.org/#/c/100968/4/specs/juno/artifact-repository.rst</a></div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font>--<br></font><div dir="ltr"><font>Regards,<br>Alexander Tivelkov</font></div></div></div>
<br><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 3, 2014 at 3:44 AM, Scott Devoid <span dir="ltr"><<a href="mailto:devoid@anl.gov" target="_blank">devoid@anl.gov</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<div dir="ltr">Hi folks,<div><br></div><div>Background:</div><div><br></div><div>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.</div>
<div><br></div><div>Why do we want this?</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Solution?</div><div><br></div><div>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.</div>
<div><br></div><div>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]</div><div><br></div><div>~ Scott</div>
<div><br></div><div>[1] <a href="https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L209" target="_blank">https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L209</a><br></div>
<div>[2] <a href="https://review.openstack.org/104377" target="_blank">https://review.openstack.org/104377</a></div>
</div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>