<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>OH! As someone who tried to champion project termination at the
API layer as a community goal during the Berlin summit, I love
that someone ran with our idea of implementing it in the SDK as a
starting point!<br>
<br>
I still think we should champion a purge API for each service, but
the SDK is definitely the place to handle dependencies, and I love
that you are doing it in threads!<br>
<br>
I'd be happy to review/test any code related to this both in the
OSC and the SDK. I sadly haven't had time to help implement
anything like this, but I will somehow find the time to
review/test! And I look forward to one day throwing away our
internal termination logic in favor of what's in the SDK!<br>
<br>
</p>
<div class="moz-cite-prefix">On 20/01/21 2:16 am, Artem Goncharov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5C651C9C-0D00-4CB8-9992-4AC23D92FE38@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hi Christian.
<div class=""><br class="">
</div>
<div class="">Actually the patch stuck due to lack of reviewers.
Idea here was not to replace “openstack project purge”, but to
add a totally new implementation (hopefully later dropping
project purge as such). From my POV at the moment there is
nothing else I was thinking to mandatorily implement on OSC side
(sure, for future I would like to give possibility to limit
services to cleanup, to add cleanup of key-airs, etc). SDK part
is completely independent of that. Here we definitely need to
add dropping of private images. Also on DNS side we can do
cleanup. Other services are tricky (while swift we can still
implement relatively easy).</div>
<div class=""><br class="">
</div>
<div class="">All in all - we can merge the PR in it’s current
form (assuming we get some positive reviews).</div>
<div class=""><br class="">
</div>
<div class="">BG,</div>
<div class="">Artem<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 19. Jan 2021, at 13:33, Christian Rohmann
<<a href="mailto:christian.rohmann@inovex.de" class=""
moz-do-not-send="true">christian.rohmann@inovex.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">Hey Artem,</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">thank you very much for
your quick reply and pointer to the patchset you work
on!<br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">On 18/01/2021 20:14, Artem
Goncharov wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:10C08D43-B4E6-4423-B561-183A4336C488@gmail.com"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<span style="caret-color: rgb(0, 0, 0);" class="">Ha,
thats exactly the case, the whole logic sits in sdk
and is spread across the supported services:</span>
<div class=""><font class="">- <a
href="https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798"
style="caret-color: rgb(0, 0, 0);" class=""
moz-do-not-send="true">https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798</a> -
for compute. KeyPairs not dropped, since they
belong to user, and not to the “project”;</font></div>
<div class="">- <a
href="https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547"
class="" moz-do-not-send="true">https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547</a> -
block storage;</div>
<div class="">- <a
href="https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490"
class="" moz-do-not-send="true">https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490</a></div>
<div class="">- <a
href="https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130"
class="" moz-do-not-send="true">https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130</a> -
the most complex one in order to give possibility to
clean “old” resource without destroying everything
else</div>
<div class=""><br class="">
</div>
<div class="">Adding image is few lines of code (never
had enough time to add it), identity is a bit
tricky, since also here mostly resources does not
belong to Project. DNS would be also easy to do. OSC
here is only providing I/F, while the logic sits in
SDK and can be very easy extended for other
services.<br class="">
</div>
</blockquote>
<br class="">
<blockquote type="cite"
cite="mid:10C08D43-B4E6-4423-B561-183A4336C488@gmail.com"
class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 18. Jan 2021, at 19:52, Thomas
Goirand <<a href="mailto:zigo@debian.org"
class="" moz-do-not-send="true">zigo@debian.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On 1/18/21 6:56 PM, Artem
Goncharov wrote:<br class="">
<blockquote type="cite" class="">What do you
mean it doesn’t implement anything at all?
It does clean up compute, network,
block_storage, orchestrate resources.
Moreover it gives you possibility to clean
“old” resources (created before or last
updated before).<br class="">
</blockquote>
<br class="">
Oh really? With that few lines of code? I'll
re-read the patch then,<br class="">
sorry for my bad assumptions.<br class="">
<br class="">
Can you point at the part that's actually
deleting the resources?<br class="">
</div>
</div>
</blockquote>
</div>
</blockquote>
<p class="">If I understood correctly, the cleanup
relies on the SDK functionality / requirement for each
resource type to provide a corresponding function(
<a class="moz-txt-link-freetext"
href="https://github.com/openstack/openstacksdk/blob/master/openstack/cloud/openstackcloud.py#L762"
moz-do-not-send="true">https://github.com/openstack/openstacksdk/blob/master/openstack/cloud/openstackcloud.py#L762</a>)
?</p>
<p class="">Reading through the (SDK) code this even
covers depending resources, nice!</p>
<p class=""><br class="">
</p>
<p class="">I certainly will leave some feedback and
comments in your change
(<a class="moz-txt-link-freetext"
href="https://review.opendev.org/c/openstack/python-openstackclient/+/734485"
moz-do-not-send="true">https://review.opendev.org/c/openstack/python-openstackclient/+/734485</a>).<br
class="">
But what are your immediate plans moving forward on
with this then, Artem? <br class="">
<br class="">
There is a little todo list in the description on your
change .. is there anything you yourself know that is
still missing before taking this to a full review and
finally merging it?<br class="">
</p>
<p class="">Only code that is shipped and then actively
used will improve further and people will notice other
required functionality or switches for later
iterations. With the current state of having a
somewhat working but unmaintained ospurge and a non
feature complete "project purge" (supports only Block
Storage v1, v2; Compute v2; Image v1, v2) this will
only cause people to start hacking away on the ospurge
codebase or worse building their own tools and scripts
to implement project cleanup for their environments
over and over again.<br class="">
</p>
<p class=""><br class="">
</p>
<p class=""><br class="">
</p>
<p class="">Regards,</p>
<p class=""><br class="">
</p>
<p class="">Christian<br class="">
</p>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</body>
</html>