runtime
runtime copied to clipboard
Adding upsert for adopt-or-create
Issue: https://github.com/aws-controllers-k8s/community/issues/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.
[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.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
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.
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.
Issues go stale after 180d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 60d 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