On Thu, Jul 24, 2014 at 9:48 AM, Scott Devoid wrote:
> So it turns out that fixing this issue is not very simple. It turns out
> that there are stubbed out openstack.common.policy checks in the glance-api
> code, which are pretty much useless because they do not use the image as a
> target. [1] T
So it turns out that fixing this issue is not very simple. It turns out
that there are stubbed out openstack.common.policy checks in the glance-api
code, which are pretty much useless because they do not use the image as a
target. [1] Then there's a chain of API / client calls where it's unclear
wh
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 curre
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 r
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 fal
