rhecosystemappeng / ansible-multicluster-cockroachdb Goto Github PK

Last night I removed 3 managed clusters around 6pm and only 2 had deleted by 8am the following morning. This task is taking an eternity but we can improve efficiency by deleting the Managed Cluster instances in parallel.

The automation flow would be to remove all three managed clusters in parallel, then immediately begin polling for the managed clusters until they do not exist, then continue the removal play.

Important Docs:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_async.html#:~:text=If%20you%20want%20to%20run,longer%20than%20its%20async%20value).

Removing the instances of the managed clusters is sometimes taking more than 12 hours.

See #28 (not much we can do about this, this is due to ACM)

This will naturally lead people to destroy the clusters and spin up new ones. The problem is that the uninstall automation cleans files that were populated from the installation process. If a new installation is started with stale orphaned files in the repo then the automation will fail at import-clusters

Is your feature request related to a problem? Please describe.
There is a deprecation warning around community.kubernetes.k8s. We may want to consider switching to kubernetes.core.k8s which has the same API.

[DEPRECATION WARNING]: community.kubernetes.k8s has been deprecated. The community.kubernetes collection is being renamed to kubernetes.core. Please update your FQCNs to kubernetes.core instead. This feature will be 
removed from community.kubernetes in version 3.0.0. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Describe the solution you'd like
Consideration of kubernetes.core.k8s.

Describe alternatives you've considered
Disabling the warning in the ansible.cfg.

Additional context
Add any other context or screenshots about the feature request here.

In the ansible multicluster cockroach automation we strive to give the user flexibility in the names given to the clusters. Due to the nature of ACM, much of the automation takes place on the ACM Hub cluster.

During testing, I named my hub cluster aws-hub instead of the traditional hub and found errors due to the context hub being hard coded in many of the tasks.

context: hub

In the group_vars we have accounted for the user to be able to name the hub using their best judgement by adding a variable:

hub_context: aws-hub

Anywhere that context is hardcoded to hub, it should be changed to:

context: "{{ hub_context }}"

Will submit a PR for this today.

Add support ACM managed clusters running on Azure.