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

bugfixes for editing managed service #763

Merged
merged 4 commits into from
Jul 5, 2022

Conversation

renan-campos
Copy link
Contributor

@renan-campos renan-campos commented Jun 28, 2022

  • Parameters not defined during service creation can now be updated.
  • Command now fails if invalid parameters are passed.

Fixes SDA-6104

@openshift-ci openshift-ci bot requested review from igoihman and vkareh June 28, 2022 11:17
@renan-campos
Copy link
Contributor Author

@tbrisker PTAL: A flag checking object was to the Rosa runtime object.
@ciaranRoche PTAL: That flag checking logic that was in the create service command has been generalized.

@renan-campos renan-campos changed the title edit service can update parameters that weren't originally defined. edit service bugfixes Jun 28, 2022
@renan-campos renan-campos changed the title edit service bugfixes bugfixes for editing managed service Jun 28, 2022
Copy link
Contributor

@tbrisker tbrisker left a comment

Choose a reason for hiding this comment

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

Not sure how I feel adding argument related logic to the runtime, perhaps we should keep a separation between them?

pkg/rosa/runtime.go Outdated Show resolved Hide resolved
"github.com/openshift/rosa/pkg/arguments"
"github.com/openshift/rosa/pkg/ocm"
"github.com/openshift/rosa/pkg/rosa"
)

var args ocm.UpdateManagedServiceArgs

var runtime *rosa.Runtime
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not too fond of using a global for the runtime (or in general)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Me neither, I thought I couldn't do it without using a global variable but I just figured out a way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please resolve this if the removal of the global variable works for you.

pkg/arguments/validator.go Outdated Show resolved Hide resolved
@renan-campos
Copy link
Contributor Author

renan-campos commented Jun 28, 2022

Not sure how I feel adding argument related logic to the runtime, perhaps we should keep a separation between them?

@tbrisker I can change it if needed, but how should we determine what goes in the runtime object? I thought the FlagChecker fit in with the other objects in the Runtime: objects that will be used during the run.

@tbrisker
Copy link
Contributor

@renan-campos I think the runtime should be limited to what happens in the run() stage of the command. That also prevents the need for the global variable. Perhaps we can add another similar object that can be used in the init() stage and handles flags, args etc. Maybe in the future we could even move some of the validations that currently run in run() to init(), but we'll need to dig a bit deeper into cobra and pflags to figure that out better.

@renan-campos
Copy link
Contributor Author

renan-campos commented Jun 29, 2022

@renan-campos I think the runtime should be limited to what happens in the run() stage of the command. That also prevents the need for the global variable. Perhaps we can add another similar object that can be used in the init() stage and handles flags, args etc. Maybe in the future we could even move some of the validations that currently run in run() to init(), but we'll need to dig a bit deeper into cobra and pflags to figure that out better.

That makes sense; Last time you reviewed the code the checker had to be globally scoped, but I changed it so that all of it occurs in the run stage. With that being the case, does it now belong in runtime, or would it still be better as a separate object?


if len(parameters) == 0 {
r.Reporter.Errorf("Service %q has no parameters to edit", args.ID)
// Setting parameter flags as valid
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems out of place?

Comment on lines 60 to 75
// Adding known flags to flag checker before parsing the unknown flags
cmd.Flags().VisitAll(func(flag *pflag.Flag) {
r.FlagChecker.AddValidFlag(flag)
})

err := arguments.ParseUnknownFlags(cmd, argv)
if err != nil {
r.Reporter.Errorf("Failed to parse flags: %v", err)
os.Exit(1)
}

if len(cmd.Flags().Args()) > 0 {
r.Reporter.Errorf("Unrecognized command line parameter")
os.Exit(1)
}

Copy link
Contributor

Choose a reason for hiding this comment

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

This looks pretty generic, maybe that be done inside WithFlagChecker()? perhaps pass cmd to the NewRuntime() method as that might be useful in other places for refactoring, or into WithFlagChecker()?

Still not sure if this should be in the runtime itself or the FlagCheck object... Perhaps lets start with the separate object and we can move it into the runtime if we see this becomes a common pattern?

Comment on lines 105 to 110
cmd.Flags().VisitAll(func(flag *pflag.Flag) {
if !r.FlagChecker.IsValidFlag(flag) {
r.Reporter.Errorf("%q is not a valid flag", flag.Name)
os.Exit(1)
}
})
Copy link
Contributor

Choose a reason for hiding this comment

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

This is also generic and perhaps shouldn't be here - if the FlagChecker has access to cmd (whether directly or via runtime) this could become something like FlagChecker.ValidateFlags()

return f
}

func (f *FlagCheck) AddValidParameter(parameterName string) *FlagCheck {
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems very addons-specific, perhaps we could combine this with AddValidFlag and have one method that accepts a string and leave it to the caller to pass the right string?

r.FlagChecker.AddValidFlag(flag)
})

err := arguments.ParseUnknownFlags(cmd, argv)
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a thought, lmk what you think:
This will add all the unknown flags to cmd.Flags() to check if they are valid later.
i'm wondering if we could perhaps flip the order around, add the flags from the addon params, and then get rid of keeping a separate set of valid flags and instead use cmd.Flags().Lookup(..) to check if a flag is valid or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The barrier to this approach is that the flags need to be parsed before the addon parameters are known.
So the flow needs to go:

  1. Parse flags
  2. Get the addon related to the service id
  3. Ensure the user provided flags are original command flags or add-on parameter flags.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Having to use some of the flags before being able to check all the flags is what really throws me off trying to get a good flow here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ParseUnknownFlags mutating the cmdFlagset doesn't help...

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure, but i think you should be able to access the known flags (which is what you need to get the other ones) even before parsing the unknown ones

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok I tried it that way.

@renan-campos
Copy link
Contributor Author

It's coming together...

@openshift-ci openshift-ci bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 30, 2022
OCMClient *ocm.Client
AWSClient aws.Client
Creator *aws.Creator
FlagChecker *arguments.FlagCheck
Copy link
Contributor

Choose a reason for hiding this comment

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

This isn't needed for now

r.FlagChecker.AddValidFlag(flag)
})

err := arguments.ParseUnknownFlags(cmd, argv)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure, but i think you should be able to access the known flags (which is what you need to get the other ones) even before parsing the unknown ones

@openshift-ci openshift-ci bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 30, 2022
@ciaranRoche
Copy link
Member

Lets merge this in, we can follow up with any other changes @tbrisker wants when he returns.

@ciaranRoche
Copy link
Member

/lgtm

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 5, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ciaranRoche, renan-campos

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

The pull request process is described 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

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 5, 2022

@renan-campos: all tests passed!

Full PR test history. Your PR dashboard.

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 understand the commands that are listed here.

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 5, 2022
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 5, 2022
@openshift-ci openshift-ci bot merged commit af324f9 into openshift:master Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants