[openstack-dev] [nova] Stein forum session notes

Tobias Rydberg tobias.rydberg at citynetwork.eu
Wed Nov 28 09:57:18 UTC 2018


On 2018-11-21 21:38, melanie witt wrote:
>>> Change of ownership of resources
>>> ================================
>>> - Ignore the network piece for now, it's the most complicated. Being
>>> able to transfer everything else would solve 90% of City Network's use
>>> cases
>>> - Some ideas around having this be a keystone auth-based access 
>>> granting
>>> instead of an update of project/user, but if keystone could hand user A
>>> a token for user B, that token would apply to all resources of user 
>>> B's,
>>> not just the ones desired for transfer
>>
>> Whatever happened with the os-chown project Dan started in Denver?
>>
>> https://github.com/kk7ds/oschown
>
> What we distilled from the forum session is that at the heart of it, 
> what is actually wanted is to be able to grant access to a resource 
> owned by project A to project B, for example. It's not so much about 
> wanting to literally change project_id/user_id from A to B. So, we 
> asked the question, "what if project A could grant access to its 
> resources to project B via keystone?" This could work if it is OK for 
> project B to gain access to _all_ of project A's resources (since we 
> currently have no way to scope access to specific resources). For a 
> use case where it is OK for project A to grant access to all of 
> project B's resources, the idea of accomplishing this is 
> keystone-only, could work. Doing it auth-based through keystone-only 
> would leave project_id/user_id and all dependencies intact, making the 
> change only at the auth/project level. It is simpler and cleaner.
>
> However, for a use case where it is not OK for project B to gain 
> access to all of project A's resources, because we lack the ability to 
> scope access to specific resources, the os-chown approach is the only 
> proposal we know of that can address it.
>
> So, depending on the use cases, we might be able to explore a keystone 
> approach. From what I gathered in the forum session, it sounded like 
> City Network might be OK with a project-wide access grant, but Oath 
> might need a resource-specific scoped access grant. If those are both 
> the case, we would find use in both a keystone access approach and the 
> os-chown approach. 

If you and others understood me that way I might have expressed me in 
the wrong way. For us, the use case we see is actually "transfer 
resources between tenants". Would say that basically all requests are 
for VMs and volumes, so that would cover most of that. As formulated in 
the forum session description, "As seamless as possible", can mean many 
different things for people, but offline approach is totally fine for my 
use case.

What we discussed (or touched) during the session was to use similar 
approach as for glance image access, but in this case use that 
invite/accept approach for the actual ownership transfer (to be clear - 
not allow someone else access to my resources).

Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181128/f3024169/attachment.html>


More information about the openstack-discuss mailing list