<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 2018-11-21 21:38, melanie witt wrote:<br>
<blockquote type="cite"
cite="mid:a2b2a462-5910-bda3-2c55-643fe6d8aea2@gmail.com">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">Change of
ownership of resources
<br>
================================
<br>
- Ignore the network piece for now, it's the most complicated.
Being
<br>
able to transfer everything else would solve 90% of City
Network's use
<br>
cases
<br>
- Some ideas around having this be a keystone auth-based
access granting
<br>
instead of an update of project/user, but if keystone could
hand user A
<br>
a token for user B, that token would apply to all resources of
user B's,
<br>
not just the ones desired for transfer
<br>
</blockquote>
<br>
Whatever happened with the os-chown project Dan started in
Denver?
<br>
<br>
<a class="moz-txt-link-freetext"
href="https://github.com/kk7ds/oschown" moz-do-not-send="true">https://github.com/kk7ds/oschown</a>
<br>
</blockquote>
<br>
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 <span
class="moz-txt-underscore"><span class="moz-txt-tag">_</span>all<span
class="moz-txt-tag">_</span></span> 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.
<br>
<br>
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.
<br>
<br>
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.
</blockquote>
<br>
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.<br>
<br>
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).<br>
<br>
<pre class="moz-signature" cols="72">Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg
<a class="moz-txt-link-abbreviated" href="http://www.citynetwork.eu">www.citynetwork.eu</a> | <a class="moz-txt-link-abbreviated" href="http://www.citycloud.com">www.citycloud.com</a>
INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED</pre>
</body>
</html>