adopt-or-create adoption policy for ResourceAdoption alpha feature

[havard024]

Creating this issue to start an open discussion on UX for the adopt-or-create adoption policy for ResourceAdoption alpha feature.

Link to ResourceAdoption alpha feature current documentation https://aws-controllers-k8s.github.io/community/docs/user-docs/features/#resourceadoption

Reference to slack discussion regarding this issue
https://kubernetes.slack.com/archives/C0402D8JJS1/p1740081894642539

Description of our use case / possible user experience:

For some aws resources that either take a long time to create, eg cloudfront distributions or other aws resources where we want to retain data, like s3 buckets or rds, we would like to keep the created resources even if the manifests defining them are deleted in kubernetes.

Use cases

• when developing kro stacks with ack

when I develop stacks using kro and ack, I often delete / recreate the stack, particularly after I think I'm done and want to see how kro behaves when there are no resources in place. If this stack contains a cloudfront distribution and I currently work on resources that depend on that distribution, if I were to delete the stack, I need to wait for the cloudfront distribution to be created again which slows down my development cycle.

That said, I might not need adopt-or-create for this use case, if I instead could delete the resources I want to create manually from k8s and trigger a kro reconciliation of the stack.

• disaster recovery / accidental deletion of k8s manifests / gitops reconciliation

to be able to reuse the manifests used to create the aws resources that has been retained

[github-actions]

Hello @havard024 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[michaelhtm]

Hello @havard024, It seems like you're describing the deletion-policy feature which we do support in ACK.
Here's the documentation.
https://aws-controllers-k8s.github.io/community/docs/user-docs/deletion-policy/

adopt-or-create feature is meant to attempt adopting a resource from AWS if it exists, if it can't find it, it tries creating it. Is that what you're looking for?

[havard024]

Hi @michaelhtm, adopt-or-create is exactly what I'm looking for.

If I have a resources with deletion-policy on and the ack manifest that created that resource disappears for any reason, I don't want to adopt the resource if it already exists instead of recreating.

accidental deletes of ack manifests using gitops where the corresponding ack resource has deletion-policy=retain

disaster recovery, the kubernetes cluster is gone, but not necessarily the aws resources, we want to adopt them instead of creating them using the same ack manifest.

[michaelhtm]

If I have a resources with deletion-policy on and the ack manifest that created that resource disappears for any reason, I don't want to adopt the resource if it already exists instead of recreating.

can you elaborate more on this? i'm not sure i understand...

[gfaraj]

Hi! I have a similar use case here:

• We have many existing AWS resources that have been created by Terraform in the past
• When deploying an application to an environment, we don't know if the AWS resource exists or not yet (it could be a new environment recently set up)
• Ideally the K8s ACK CR would define the new desired state of either an existing AWS resource, or a new AWS resource.

Right now I'm getting this error:

QueueAlreadyExists: A queue already exists with the same name and a
different value for tags

Hoping this gets traction soon!

[JonathanGraniero]

Hello! Similar to what @gfaraj mentioned, I'm working on a project currently that is in the same boat, we have a lot of resources that are created in terraform, and we are looking to do the migration to using ACK.

The issue we are running into is that we want to define one resource definition, and have it deployable across multiple deployments. This means that right now we have to have complex logic or specific workflows around adopting a resource, then back porting the adopted resource. We would love to have a mechanism to add an annotation for adopt-or-create so that way it'll automatically create the resource if it doesn't exist, and for existing deployments it doesn't create any new resources and we still have visibility into maintaining those resources.

[havard024]

If I have a resources with deletion-policy on and the ack manifest that created that resource disappears for any reason, I don't want to adopt the resource if it already exists instead of recreating.

can you elaborate more on this? i'm not sure i understand...

@michaelhtm sorry about that, it basically as @gfaraj mentioned, if you have an existing aws resources with no ack manifest defined (eg you are migrating from something else to ack) or if you have an ack manifest with deletion-policy set to retain and for some reason lose the ack manifest (eg accidental delete), I can't add the ack manifest back because it will try to create a new resource.

With a adopt-or-create policy, we expect ack to take control over the state when adopting the resource back.

[michaelhtm]

Hello, We have an initial implementation in the works. Will keep you all updated on here!

[gfaraj]

Hi @michaelhtm -- looks like this change was merged, nice! Is this planned to be released soon?

[michaelhtm]

Hi @gfaraj
Yes, we are starting the release process soon!