-
Notifications
You must be signed in to change notification settings - Fork 768
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 issue in extraCommandArgs field #1541
base: master
Are you sure you want to change the base?
Conversation
c2b7eb0
to
e8ed105
Compare
controllers/argocd/deployment.go
Outdated
// If this flag already exists in cmd, skip it | ||
if _, exists := existingArgs[arg]; exists { | ||
if i+1 < len(extraArgs) && !strings.HasPrefix(extraArgs[i+1], "--") { | ||
i++ // Skip the associated value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if an existing flag is added with a new value, will that also be skipped?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it is skipped
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that the expected behavior? what if the user wants to change the current flag value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
based on the existing unit test https://github.com/argoproj-labs/argocd-operator/blob/master/controllers/argocd/deployment_test.go#L1304 which is updating existing cmd i.e --redis command, I think this is expected behaviour, I might be wrong and open for suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, maybe we can confirm with others as well. Otherwise looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think users should be allowed to override default flags. There may be cases where tuning of default params could be useful.
e8ed105
to
06d0795
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any logic to address the 3rd problem reported in the Jira issue
3. Adding argument and value as a single element causes the pod to crash
Other than that, it looks good to me.
Thanks John, for 3rd point -
|
|
Re-ran the tests |
Signed-off-by: Rizwana777 <[email protected]>
All the tests are passing now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Rizwana777 - Can we allow users to override params? There may be cases where tuning of default params could be useful.
14f8f29
to
9624248
Compare
Signed-off-by: Rizwana777 <[email protected]>
9624248
to
0079ddb
Compare
@svghadi I have updated the code which allow the users to override existing params, PTAL |
JIRA - https://issues.redhat.com/browse/GITOPS-5200