Automatic adoption of ACK created resources

[rgarrigue]

Is your feature request related to a problem?

We're running ArgoCD. And using ACK RDS to create a service's database along with it. To avoid any accident, termination protection is enabled. The accident did happened, the database was properly safeguarded, but now the DBInstance resource says in its status

This resource already exists but is not managed by ACK. To bring the resource under ACK management, you should explicitly adopt the resource by creating a services.k8s.aws/AdoptedResource

Describe the solution you'd like

I'ld like ACK to auto adopt back the resource.

I can imagin something like automatically adding a pair of "owner-by: this-ack" plus "ack-auto-adopt: yes" tags, roughtly like the cluster-autoscaler do.

Describe alternatives you've considered

Either leave it as is, but no further update will be possible, I really don't like it.

Or see if I can create the AdoptedResource straight away, hopefully it'll be successful even if there's no need for it

[a-hilaly]

Hi @rgarrigue i am not able to fully understand why adopted resources don't work for your case? could you please provide the yaml manifests of you're trying to apply?

[jkatz]

@a-hilaly I think I would term this under "autodiscovery" of resources. I believe the suggested workflow would be:

1. There exists AWS resources (e.g. an RDS DBInstance) with tags that follow a user-defined pattern (e.g. "managed-by": "ack").
2. In the ACK controller, we either 1/ allow a user to set an environmental variable called AUTODISCOVER_TAGS or 2/ have a new custom resource called AutodiscoverResource and we provide one or more tags that the controller would look when searching for resources
3. Periodically (period to be defined) the ACK controller looks to see if there are any new AWS resources that match the autodiscovery pattern.
4. If a new resource is found, ACK will create a new resource for that object and allow the user to manage it from ACK

Does that make sense? @rgarrigue Does that align with your thinking?

[rgarrigue]

@a-hilaly AdoptedResource will most likely work : from my first trial I see the AdoptedResource return ✅ if nothing to do, so once properly setup it should do the job of adopting back a previously created DB if needed & no breaking the whole argocd app with a failure. I can't provide the manifest atm, still got moving parts

@jkatz not exactly. What I want is a sort of idempotence / declarative behavior. I want a database running and ArgoCD ✅ . First execution ? Database created. ArgoCD application got removed - database is still here due to database protection - and ArgoCD application is created again ? Database adopted. Seems DBInstance/Cluster plus AdoptedResource should fit my use case

If it works, guess it will, this issue can be marked as resolved

But.

I'ld argue that it could be simpler. DBInstance / DBCluster resources tell me "already exist". Why not adopting then, without the operator having to create an additional AdoptResource resource ? Provided an "auto-adopt: true" attribute is set by the user. And/or tags "owned-by: this-ack if you deem it necessary.

Maybe I'm nitpicking, asking for a "I'm lazy, make my life easier" feature. But so far I found the ACK RDS experience rough, so could be said to be a UX improvement

[RedbackThomson]

I feel like this discussion is inline with a previous issue - #1381

[ack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/aws-controllers-k8s/community.
/lifecycle stale

[a-hilaly]

duplicate of #1381
/close

[ack-prow]

@a-hilaly: Closing this issue.

In response to this:

duplicate of #1381
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.