<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 21, 2019 at 1:17 PM Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Jan 21, 2019, at 3:10 AM, Jean-Philippe Evrard <<a href="mailto:jean-philippe@evrard.me" target="_blank">jean-philippe@evrard.me</a>> wrote:<br>
> <br>
> I think it would be great to have a larger community feedback, or at<br>
> least a API SIG feedback, analysing this pattern.<br>
<br>
I would strongly prefer the approach of each service implementing an endpoint to be called by the Keystone when a project is deleted. Relying on a library that would somehow be able to understand all the parts a project touches within a service sounds a lot more error-prone.<br></blockquote><div><br></div><div>Are you referring to the system scope approach detailed on line 38, here [0]? I might be misunderstanding something, but I didn't think keystone was going to iterate all available services and call clean-up APIs. I think it was just that services would be able to expose an endpoint that cleans up resources without a project scoped token (e.g., it would be system scoped [1]).</div><div><br></div><div>[0] <a href="https://etherpad.openstack.org/p/community-goal-project-deletion">https://etherpad.openstack.org/p/community-goal-project-deletion</a></div><div>[1] <a href="https://docs.openstack.org/keystone/latest/admin/tokens-overview.html#system-scoped-tokens">https://docs.openstack.org/keystone/latest/admin/tokens-overview.html#system-scoped-tokens</a> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
-- Ed Leafe<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div></div></div>