Mailing List Archive

[glance] share image with domain
It is possible to add a domain as a member, however this is not taken in account. It should be mentioned that you can also add non-existing project ids as a member.

For me it looks like it is not possible to share a image with visibility “shared” with a domain.

Are there known workarounds or scripts for that use case?

Christian.

--
Christian Berendt
Chief Executive Officer (CEO)

Mail: berendt@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [glance] share image with domain [ In reply to ]
On Tue, Jul 10, 2018 at 8:04 AM Christian Berendt
<berendt@betacloud-solutions.de> wrote:

> It is possible to add a domain as a member, however this is not taken in account. It should be mentioned that you can also add non-existing project ids as a member.

Yes, you can add any string as an image member. Back when image
sharing was implemented, it was thought that making an extra call to
keystone to verify the member_id would be too expensive because people
would be sharing so many images all the time, but AFAIK, that hasn't
turned out to be the case. So it may be worth revisiting this issue.

> For me it looks like it is not possible to share a image with visibility “shared” with a domain.

That is correct, the items in the member-list are treated as project
IDs. (Actually, that's not entirely true, but will be completely true
very early in the Stein development cycle.[0])

> Are there known workarounds or scripts for that use case?

I'm not aware of any. You could write a script that took a domain ID,
got the list of projects in that domain, and shared the image with all
those projects, but then you'd have a synchronization problem when
projects were added to/removed from the domain, so that's probably not
a good idea.

If this is an important use case, please consider proposing a Glance
spec [1] or proposing it as a topic for the upcoming PTG [2].

cheers,
brian

[0] https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/spec-lite-deprecate-owner_is_tenant.html
[1] http://git.openstack.org/cgit/openstack/glance-specs
[2] https://etherpad.openstack.org/p/stein-ptg-glance-planning

> Christian.
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: berendt@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [glance] share image with domain [ In reply to ]
On 08/22/2018 11:05 AM, Brian Rosmaita wrote:
> On Tue, Jul 10, 2018 at 8:04 AM Christian Berendt
> <berendt@betacloud-solutions.de> wrote:
>
>> It is possible to add a domain as a member, however this is not taken in account. It should be mentioned that you can also add non-existing project ids as a member.
>
> Yes, you can add any string as an image member. Back when image
> sharing was implemented, it was thought that making an extra call to
> keystone to verify the member_id would be too expensive because people
> would be sharing so many images all the time, but AFAIK, that hasn't
> turned out to be the case. So it may be worth revisiting this issue.

It's not just that. It's that if someone then deletes the project from
Keystone, it's not like Glance listens for that project delete
notification and takes some remediation.

Instead, Glance would just keep a now-orphaned project ID in its
membership data store. Which is perfectly fine IMHO. Is it ideal? No,
but does it hurt anything? Not really... You could make some cleanup
out-of-band process that looked for orphaned information and cleaned it
up later on.

Such is the life of highly distributed services with no single data
store that uses referential integrity... :)

Best,
-jay

>> For me it looks like it is not possible to share a image with visibility “shared” with a domain.
>
> That is correct, the items in the member-list are treated as project
> IDs. (Actually, that's not entirely true, but will be completely true
> very early in the Stein development cycle.[0])
>
>> Are there known workarounds or scripts for that use case?
>
> I'm not aware of any. You could write a script that took a domain ID,
> got the list of projects in that domain, and shared the image with all
> those projects, but then you'd have a synchronization problem when
> projects were added to/removed from the domain, so that's probably not
> a good idea.
>
> If this is an important use case, please consider proposing a Glance
> spec [1] or proposing it as a topic for the upcoming PTG [2].
>
> cheers,
> brian
>
> [0] https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/spec-lite-deprecate-owner_is_tenant.html
> [1] http://git.openstack.org/cgit/openstack/glance-specs
> [2] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>
>> Christian.
>>
>> --
>> Christian Berendt
>> Chief Executive Officer (CEO)
>>
>> Mail: berendt@betacloud-solutions.de
>> Web: https://www.betacloud-solutions.de
>>
>> Betacloud Solutions GmbH
>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>
>> Geschäftsführer: Christian Berendt
>> Unternehmenssitz: Stuttgart
>> Amtsgericht: Stuttgart, HRB 756139
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators