Unified/Simplified Cloud Provider Cleanup and Resource Types

[jyejare]

Multiple Changes that simplifies contribution now:

• The Dry run setting is now available directly from settings globally, hence need not to pass the context in click subcommands. (But we need to until we do translate all cloud providers and resource types in new code standards)
• New entities/providers.py module contains the base class providerCleanup that holds the resource_type properties for all common resource types. Also contains the individual cloud provider class for non-common resource types for that cloud specific resource type.
• New entitites/resources package contains the modules for every resource type for all the cloud providers. Those resource type modules contains a common base class and common functions applicable for all cloud providers and could be overridden from individual cloud provider resource type class.
• Now providers packages cloud provider module just imports the cleanup class for that cloud provider. And then the applicable resource types properties would be called for cleanup easily.
  e.g from cloudwash.entities.providers import AWSCleanup; awscleanup= AWSCleanup(client=aws_client); awscleanup.vms.cleanup(); awscleanup.discs.cleanup(), Same example applies for all other cloudproviders.

[omkarkhatavkar]

@jyejare one more approach to solve this to remove more coupling and adding more providers and reduce the factory pattern made in parent class. let me know what you think about it

class ProviderCleanup:
    def __init__(self, client, vm_cleaner, disc_cleaner):
        self.client = client
        self.vm_cleaner = vm_cleaner
        self.disc_cleaner = disc_cleaner

    def vms(self):
        return self.vm_cleaner.clean(self.client)

    def discs(self):
        return self.disc_cleaner.clean(self.client)


class AzureCleanup(ProviderCleanup):
    def __init__(self, client):
        super().__init__(client, CleanAzureVMs(), CleanAzureDiscs())


class AWSCleanup(ProviderCleanup):
    def __init__(self, client):
        super().__init__(client, CleanAWSVms(), CleanAWSDiscs())

[jyejare]

Hmm!

I see multiple issues in this pattern:

1. Unnecessary Object Initialization of CloudProviderResourceType classes (e.g CleanAzureVMs(client), CleanAzureDiscs(client)) even though its not demanded! That also takes a huge time for all classes initialization. For now its the object creation is on demand and explicit if its demanded!
2. The list of parameters will increase in endless number as and when number of resource types will grow. Though we can control it with kwargs, but its extra layer of verification if the object is available in params.
3. In current design, if the non-common resource type property is needed to be added then you can do it at that cloud provider class level and dont need to send it back to base class for processing / returning.

For now, I can only think of these issues! Feel free to reply with the thoughts !

[omkarkhatavkar]

Okay, I ack it.

[omkarkhatavkar]

not sure how this is working ? is that intentional ?

[jyejare]

Yes it is intentional. As soon as the class is initiated the listing should happen and all dry data must be updated for viewing without calling the explicit cleanup() method.

[jyejare]

This also helps in if user just wanted to list / stop or any other method without actually cleaning it or calling that function !

[omkarkhatavkar]

ACK