Adding upsert for adopt-or-create

[JonathanGraniero]

Issue: aws-controllers-k8s/community#2481

Description of changes:

When using the adopt-or-create annotation, the current functionality is that it will come up with reconcile errors if you are trying to adopting an existing resource on second reconcile. What is happening is that when there are differences in the spec compared to what is deployed, it's error'ing out and failing due to a mismatch on resources.

In most cases, the resource values in ACK should be the accepted source of truth and this should be an upsert.

The goal of this PR is that the desired manifest should be set as the latest manifest, so that when the controller reconciles the changes, it overrides the deployed values with the values in the spec section from the resource manifest.

For example, I have a queue named my-queue that is currently deployed. All of the resources are the same as below. The exception would be visibilityTimeout which is set at 300.

apiVersion: sqs.services.k8s.aws/v1alpha1
kind: Queue
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: '-1'
  services.k8s.aws/adoption-policy: adopt-or-create
  finalizers:
    - finalizers.sqs.services.k8s.aws/Queue
  generation: 2
  labels:
    app: my-app
    app.kubernetes.io/instance: my-app
    queue-type: primary
  name: my-queue
  namespace: namespace
spec:
  delaySeconds: '0'
  maximumMessageSize: '262144'
  messageRetentionPeriod: '1209600'
  queueName: my-queue
  receiveMessageWaitTimeSeconds: '0'
  visibilityTimeout: 30

I would expect the visibility timeout to be updated on my deployed queue to be 30 rather than the 300 that is currently deployed. The current behavior is that this would fail to reconcile due to a mismatch on the field.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ack-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: JonathanGraniero
Once this PR has been reviewed and has the lgtm label, please assign michaelhtm for approval by writing /assign @michaelhtm in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ack-prow]

Hi @JonathanGraniero. Thanks for your PR.

I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[JonathanGraniero]

I'm going to open this when it's ready to review, I'm still working on the test but just opened this in draft to visibly see my changes before making filling out the details.

[michaelhtm]

Hello @JonathanGraniero
Thank you for the contribution!
Left one inline comment!

[michaelhtm]

👍

[michaelhtm]

For this one, we were planning on implementing a different method.
Instead of PopulateResourceFromAnnotation we can give the method context of whether it is adopt or adopt-or-create. This will allow it to either Populate both Spec and Status, or only Status.

Honestly i'm not sure what the expected Error should be if you need to provide a required field in Status on adopt-or-create but you fail to do so. Should that be a terminal error? Or just return nothing, and just create the resource...
cc: @gfaraj @havard024

[JonathanGraniero]

I'm open to suggestions here, what I was trying to solve for here is that in the process of doing my migration, I found that I had some resources that were setup incorrectly and were not standardized. So I want to standardize them in one shot rather than doing first getting the reconciler to accept the adopted policy, then go and remove the extra code that I was just doing to be able to adopt the resource.

If this is in line with what y'all need to, or you need me to add some more branching logic, totally up to adding that in here.

[michaelhtm]

Can you test your use case with the latest released controllers? I believe this issue came up before, and we just cut releases for it today..

[michaelhtm]

can you also create an issue describing the issue you encountered? just in case we also have it in other controllers

[JonathanGraniero]

Done! aws-controllers-k8s/community#2481 I'll also update that in the PR description

[michaelhtm]

Thank you @JonathanGraniero
just responded on the Github issue. I believe this was resolved in the latest release