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: Fix duplicate cluster-level resources with namespace when printing during execution of CLI commands (issue #18669) #19830

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

thecooldrop
Copy link
Contributor

As per title there was an issue in CLI where:

  • When cluster-scoped resource is included in Application
  • And cluster-scoped resource is assigned metadata.namespace field:

Then during printing in CLI commands the resource would be printed out twice. This has now fixed in hopefully all code paths.

I am unsure if this change needs cherry-picking into older versions. I kindly ask the maintainers to guide me here.

Closes issue #18669

Checklist:

  • Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
  • The title of the PR states what changed and the related issues number (used for the release note).
  • The title of the PR conforms to the Toolchain Guide
  • I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
  • I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
  • Does this PR require documentation updates? => No
  • I've updated documentation as required by this PR.
  • I have signed off all my commits as required by DCO
  • I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
  • My build is green (troubleshooting builds).
  • My new feature complies with the feature status guidelines.
  • I have added a brief description of why this PR is necessary and/or what this PR solves.
  • Optional. My organization is added to USERS.md.
  • Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

…sources

In this commit many changes have been made in order to prevent double printing
of cluster level resources. The bug was as follows: When Application contained
a cluster-level resource with metadata.namespace field specified, then
any operations which printed the Application resources with wide output format
would print the cluster-level resources twice. The resource would be printed
once with namespace and second time without namespace.

The bug is caused by difference in how ArgoCD saves the list of Application
resources in Application.status.resources field
and in Application.status.operationState.syncResult.resources field. Both
of these fields taken into consideration when printing, but in
Application.status.resources field the cluster-level resources are written
with namespace set to "", no matter what was specified in original YAMLs,
while in second location they are saved with namespace fully written out.
This prevented the existing mechanisms from detecting that specific
cluster-level resource has already been printed.

In this commit I have:

- Implemented a new mechanism for retrieving resources from both lists
  which ensures that there are no duplications
- Adapted all of the commands which printed resources (most of them just transitively relied on waitOnApplicationStatus, which actually printed)
- Adapted the fake testing client to include a cluster-level resource in order to be able to test this behavior
- Adapted the test of waitOnApplicationStatus to ensure that new behavior is as expected

Signed-off-by: TheCoolDrop <[email protected]>
… in print

During deduplication of cluster level resources, if resource representation
from operationState.syncResult came earlier, then the message would have been
discarded. The code has been adapted to take this into consideration
by merging, and the test has been adapted to include the message.

Signed-off-by: TheCoolDrop <[email protected]>
@thecooldrop thecooldrop requested a review from a team as a code owner September 7, 2024 18:03
Copy link

bunnyshell bot commented Sep 7, 2024

🔴 Preview Environment stopped on Bunnyshell

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

  • 🔵 /bns:start to start the environment
  • 🚀 /bns:deploy to redeploy the environment
  • /bns:delete to remove the environment

Copy link

bunnyshell bot commented Sep 7, 2024

✅ Preview Environment created on Bunnyshell but will not be auto-deployed

See: Environment Details

Available commands (reply to this comment):

  • 🚀 /bns:deploy to deploy the environment

@@ -93,8 +93,7 @@ COPY ./test/container/entrypoint.sh /usr/local/bin
ARG UID

# Prepare user configuration & build environments
RUN userdel -r ubuntu && \
Copy link
Contributor

Choose a reason for hiding this comment

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

Why remove this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That was an intermittent change, which I will revert. The issue is that when I try to build locally it tells me that email spool, or similar, is missing for user, and thus can not be deleted.

I have commented about this issue here: #18917 (comment)

The PR was already closed sadly.

groupVersion += (resource.Group + "/")
}
groupVersion += resource.Version
apiResourceList, err := discoveryClient.ServerResourcesForGroupVersion(groupVersion)
Copy link
Contributor

Choose a reason for hiding this comment

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

This call looks like it might be slow.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe, but this code path is only traversed from CLI commands, and how slow can it be? It boils down to few HTTP requests at most.

for _, apiResource := range apiResourceList.APIResources {
if resource.Group == apiResource.Group && resource.Version == apiResource.Version && resource.Kind == apiResource.Kind {
if !apiResource.Namespaced {
resource.Namespace = ""
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we update the backend to properly handle this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am unsure to what case are you refering. Could you please explain what you would like to have changed, and where?

Copy link
Contributor

Choose a reason for hiding this comment

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

Essentially to not overrride the namespace in CLI, but make ArgoCD not set it in the first place for cluster resources, or unset it before returning data to CLI.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That does make sense, and was part of my initial analysis. I will have to dig significantly deeper though, and it may take me up to next week ( since I am basically clueless about ArgoCD codebase ). My assumption currently is though that this happens in GitOps Engine library. I made a quite thorough analysis about the cause of the bug in the issue this PR belongs to.

@andrii-korotkov-verkada
Copy link
Contributor

Fix the tests, please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants