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

Dan Smith dms at danplanet.com
Tue Nov 27 16:32:40 UTC 2018

>>> 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.

FWIW, this is not what I gathered from the discussion, and I don't see
anything about that on the etherpad:


I know the self-service project-wide grant of access was brought up, but
I don't recall any of the operators present saying that would actually
solve their use cases (including City Network). I'm not really sure how
granting another project access to all resources of another is really
anything other than a temporary solution applicable in cases where
supreme trust exists.

I could be wrong, but I thought they specifically still wanted an API in
each project that would forcibly transfer (i.e. actually change
userid/project on) resources. Did I miss something in the hallway track


More information about the openstack-discuss mailing list