Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion
Adrian Turjak
adriant at catalystcloud.nz
Tue Feb 2 07:40:22 UTC 2021
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!
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!
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!
On 20/01/21 2:16 am, Artem Goncharov wrote:
> Hi Christian.
>
> 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).
>
> All in all - we can merge the PR in it’s current form (assuming we get
> some positive reviews).
>
> BG,
> Artem
>
>> On 19. Jan 2021, at 13:33, Christian Rohmann
>> <christian.rohmann at inovex.de <mailto:christian.rohmann at inovex.de>> wrote:
>>
>> Hey Artem,
>>
>> thank you very much for your quick reply and pointer to the patchset
>> you work on!
>>
>>
>>
>> On 18/01/2021 20:14, Artem Goncharov wrote:
>>> Ha, thats exactly the case, the whole logic sits in sdk and is
>>> spread across the supported services:
>>> -
>>> https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798
>>> <https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798> -
>>> for compute. KeyPairs not dropped, since they belong to user, and
>>> not to the “project”;
>>> -
>>> https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547
>>> <https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547> -
>>> block storage;
>>> -
>>> https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490
>>> <https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490>
>>> -
>>> https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130
>>> <https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130> -
>>> the most complex one in order to give possibility to clean “old”
>>> resource without destroying everything else
>>>
>>> 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.
>>
>>>> On 18. Jan 2021, at 19:52, Thomas Goirand <zigo at debian.org
>>>> <mailto:zigo at debian.org>> wrote:
>>>>
>>>> On 1/18/21 6:56 PM, Artem Goncharov wrote:
>>>>> 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).
>>>>
>>>> Oh really? With that few lines of code? I'll re-read the patch then,
>>>> sorry for my bad assumptions.
>>>>
>>>> Can you point at the part that's actually deleting the resources?
>>
>> If I understood correctly, the cleanup relies on the SDK
>> functionality / requirement for each resource type to provide a
>> corresponding function(
>> https://github.com/openstack/openstacksdk/blob/master/openstack/cloud/openstackcloud.py#L762)
>> ?
>>
>> Reading through the (SDK) code this even covers depending resources,
>> nice!
>>
>>
>> I certainly will leave some feedback and comments in your change
>> (https://review.opendev.org/c/openstack/python-openstackclient/+/734485).
>> But what are your immediate plans moving forward on with this then,
>> Artem?
>>
>> 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?
>>
>> 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.
>>
>>
>>
>> Regards,
>>
>>
>> Christian
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210202/9e5ddfce/attachment-0001.html>
More information about the openstack-discuss
mailing list