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