Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bug where ArgoCD removes nodePlacement stanza from configuration #740

Merged
merged 2 commits into from
Aug 9, 2024

Conversation

Rizwana777
Copy link
Collaborator

@Rizwana777 Rizwana777 commented Jul 3, 2024

What type of PR is this?
/kind bug

JIRA - https://issues.redhat.com/browse/GITOPS-4185

We were not able to patch the NodePlacement directly through ArgoCD CR, if we do, it removes the nodePlacement from ArgoCD CR while reconciling because of this https://github.com/redhat-developer/gitops-operator/blob/master/controllers/gitopsservice_controller.go#L475 here defaultArgoCDInstance.Spec.NodePlacement is nil as it not getting updated anywhere else in code, defaultArgoCDInstance.Spec.NodePlacement is only getting updated if we update it through GitOpsService CR or else it update existingArgoCD.Spec.NodePlacement as nil because of the reason I have mentioned above , but if a user wants to add custom nodePlacement he/she should patch nodePlacement through GitOpsService CR and it is working as expected I see no bug in code and code is valid

if len(instance.Spec.NodeSelector) > 0 {

I have updated the code here -

// Checking if default nodePlacement is nil to verify whether the patch is done using GitopService CR or ArgoCD CR

which is checking for nil , the logic mentioned in the PR states that , it will check for defaultArgoCDInstance.Spec.NodePlacement not equal to nil (it means nodePlacePlacement is updated through GitOps service CR and the values got updated here in if condition) else it will not enter the if condition to check if defaultArgoCDInstance.Spec.NodePlacement is nil (it means nodePlacePlacement is updated through ArgoCD by user and it should not replace the existingArgoCD with nil value, that is the changes made by user will not get reverted back as mentioned in the bug when it reconciles)

This is what I have came up with for the bug mentioned above, please do let me know your suggestions, thank you

@openshift-ci openshift-ci bot added the kind/bug Something isn't working label Jul 3, 2024
@openshift-ci openshift-ci bot requested review from varshab1210 and wtam2018 July 3, 2024 11:14
@Rizwana777
Copy link
Collaborator Author

/retest

1 similar comment
@jgwest
Copy link
Collaborator

jgwest commented Jul 7, 2024

/retest

existingArgoCD.Spec.NodePlacement = defaultArgoCDInstance.Spec.NodePlacement
changed = true
// Checking if default nodePlacement is nil to verify whether the patch is done using GitopService CR or ArgoCD CR
// if user is patching nodePlacement through GitopsService CR, then the above written logic for GitopsService will add custom values to defaultArgoCDInstance's nodePlacement,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic is that unless any change is made in GitopService CR, don't check the nodePlacement spec right?
That will allow users to manage the default instance via ArgoCD CR.

The comment is confusing and not sure if needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the bug, user is trying to patch nodePlacement using oc patch argocd ... and logic present is checking for nodePlacement when user tries to patch using gitopsservice oc patch gitopsservice ... . Basically in comment it is mentioned that if the user is trying to patch argocd using gitopsservice then defaultArgoCDInstance.Spec.NodePlacement will not be nil and it will update argocd(i.e, existingArgoCD.Spec.NodePlacement ) based on that, otherwise defaultArgoCDInstance.Spec.NodePlacement will be nil and it will not update the existingArgoCD.Spec.NodePlacement now as I have added If condition here to check this, I have added the explanation in the description, please let me know if its not making sense

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, what Saumeya is trying to convey is, instead of this comment i.e. explaining how this part of code works, if we can just reduce the comment to what it does.
Maybe we can just write

     // if user is patching nodePlacement through GitopsService CR, then existingAgoCd NodePlacement is updated.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it, I will update this, thanks Saumeya and Anand

@saumeya
Copy link
Member

saumeya commented Jul 8, 2024

Also, did you verify why the users are unable to patch the resource via the GitopService CR? why does that not add the required nodeSelectors, maybe there is another bug in that.

@Rizwana777
Copy link
Collaborator Author

Also, did you verify why the users are unable to patch the resource via the GitopService CR? why does that not add the required nodeSelectors, maybe there is another bug in that.

Yes I tried reproducing both the bugs , I reproduced one of the bug where user is trying to patch using argocd (oc patch argocd) and the second one((oc patch gitopsservice) I did not see this bug, I tried every steps to reproduce it, but not seeing this bug and I am able to patch argocd via GitopsService CR

Copy link

openshift-ci bot commented Jul 18, 2024

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign svghadi for approval. 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:

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

@Rizwana777
Copy link
Collaborator Author

/retest

Copy link
Collaborator

@jgwest jgwest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix LGTM, could we get some unit tests for this case?

@Rizwana777
Copy link
Collaborator Author

/retest

@jgwest
Copy link
Collaborator

jgwest commented Jul 25, 2024

LGTM, rebasing to latest to see if that fixes the test failures

@jgwest
Copy link
Collaborator

jgwest commented Aug 1, 2024

/retest

@Rizwana777
Copy link
Collaborator Author

/test v4.12-kuttl-sequential

@Rizwana777
Copy link
Collaborator Author

/retest

@jgwest
Copy link
Collaborator

jgwest commented Aug 2, 2024

CI issue?

/retest

@varshab1210
Copy link
Member

Hi @jgwest, there are four sequential test failures that are recurring for this PR so I don't think re trigger would help. Retesting without proper investigation leads to more resource consumption and at the moment we are trying to minimise our cloud cost. I have suggested @Rizwana777 to take a look at the tests that are failing and run them individually with her change to debug further, maybe some tests need updates?

1-071_validate_node_selectors
1-028_validate_run_on_infra
1-020_validate_redis_ha_nonha (might not be related but worth checking since it fails for this PR only)
1-035_validate_argocd_secret_repopulate (might not be related but worth checking since it fails for this PR only)

Sequential test history:
https://prow.ci.openshift.org/job-history/gs/test-platform-results/pr-logs/directory/pull-ci-redhat-developer-gitops-operator-master-v4.12-kuttl-sequential
https://prow.ci.openshift.org/job-history/gs/test-platform-results/pr-logs/directory/pull-ci-redhat-developer-gitops-operator-master-v4.13-kuttl-sequential
https://prow.ci.openshift.org/job-history/gs/test-platform-results/pr-logs/directory/pull-ci-redhat-developer-gitops-operator-master-v4.14-kuttl-sequential

Copy link
Collaborator

@jgwest jgwest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @Rizwana777, and thanks everyone for your reviews/input!

@jgwest jgwest merged commit eee7b8a into redhat-developer:master Aug 9, 2024
19 of 20 checks passed
trdoyle81 pushed a commit to trdoyle81/gitops-operator that referenced this pull request Aug 13, 2024
…edhat-developer#740)

* Fix bug where ArgoCD removes nodePlacement stanza from configuration

Signed-off-by: Rizwana777 <[email protected]>

* Add unit test for argocd nodeplacement

Signed-off-by: Rizwana777 <[email protected]>

---------

Signed-off-by: Rizwana777 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants