-
Notifications
You must be signed in to change notification settings - Fork 13
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
Add pgo show ha
command and add combined output to pgo show
#77
Conversation
21406e1
to
75e9a01
Compare
5cc312b
to
e0b344d
Compare
cmdShow.Args = cobra.ExactArgs(1) | ||
|
||
// Define the 'show backup' command | ||
cmdShow.RunE = func(cmd *cobra.Command, args []string) error { |
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.
This is pretty tidy (helped by the choice of spinning off getPrimaryExec
as a helper func), but I wonder if it would be better to do something like:
<print backup header>
newShowBackupCommand(config).Execute()
<print HA header>
newShowHACommand(config).Execute()
That way this show will never drift from those child func implementations. (And if we need to set args before executing, there's SetArgs
-- though I wonder if a child cmd's execute inherits those args already?)
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.
👍 Good idea. I'll give that a shot.
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.
That seems to work well, with a couple of adjustments:
- using
Execute
doesn't work because the sub-command will treat bothshow
and the cluster name as arguments. The way to do this is to invokeRunE
directly. - I had to pass through
cmd
andargs
. This is fine as both sub-commands take one and only one argument, but this could get trickier in the future if different commands required different arguments. In that case, I think we would need to useSetArgs
as you suggested.
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.
Hmmm, just to check, if you do
showCmd := newShowHACommand(config)
err := showCmd.Execute()
it fails because it's only expecting one argument?
Oh, I wonder if this is the issue here: https://github.com/spf13/cobra/blob/v1.7.0/command.go#L1011C1-L1012
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.
From testing, what I was seeing is that the show
command had my cluster name as its only arg, but once show backup
was invoked, the arg list contained show
and the cluster name. Since the command can only accept one argument, it would fail immediately.
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 mean, we might be wanting to "run show ha" [logic/behavior] without invoking Cobra to do it.
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, gotcha. That's how I had it previously (which is what started this comment thread). The benefit with this approach is that we only define the logic once, but it wouldn't be hard to revert to the older approach if that's what we'd like to do here. What is the downside to invoking Cobra in this way?
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 the idea that Chris is pointing at is:
ORIGINAL
showBackup: code to do A
showHA: code to do B
show: code to do A and code to do B
MY IDEA
showBackup: code to do A
showHA: code to do B
show: showBackup(), showHA() # invoke cobra
CHRIS'S IDEA
showBackup: backupFunc()
showHA: haFunc()
show: backupFunc(), haFunc() # just call the logic
This is like the idea that I'm trying out in the separate-concerns
branch here.
The benefit of invoking Cobra is that it does all the pre and post, etc., if we need it, which we currently don't. (Separating out the logic from the Cobra does make it easier to test without calling KUTTL.) But this does keep us from repeating logic.
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, we might need to touch base to make sure I'm following. It looks like we'd need to pull in a lot from the cobra implementation in a way that seems cluttered to me, but maybe I'm missing something.
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.
Pushed updates based on discussion with @benjaminjb.
e0b344d
to
e0b8162
Compare
Adds a new subcommand to pgo show, 'ha', which provides the 'patronictl list' command info when invoked. Issue: PGO-13
e0b8162
to
da8e23a
Compare
da8e23a
to
80f2230
Compare
This commit adds the default output from 'pgo show backup' and 'pgo show ha' to the 'pgo show' command. Issue: PGO-13
Adds enum based output format flag validation as well as a KUTTL TestStep to check for the desired behavior.
80f2230
to
51c894b
Compare
c903c97
to
d13dd37
Compare
} else { | ||
cmd.Printf(stdout) | ||
if stderr != "" { | ||
cmd.Printf("\nError returned: %s\n", stderr) |
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.
cmd.Printf("\nError returned: %s\n", stderr) | |
cmd.Printf("\nError returned from backup: %s\n", stderr) |
?
Or will the stderr be clear?
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.
It should generally be clear, but I don't think that's guaranteed. Maybe Error returned from pgBackRest
would be clearer?
|
||
// String is used both by fmt.Print and by Cobra in help text | ||
func (e *patroniFormat) String() string { | ||
return string(*e) | ||
} | ||
|
||
// Set must have pointer receiver so it doesn't change the value of a copy |
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 wonder if this file could use some code comments up top to explain where the form for this type is coming from. (Is it here: https://github.com/spf13/pflag/blob/master/flag.go#L187 ?)
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.
Sure, I can add a comment. That's the right part, I think linking to https://pkg.go.dev/github.com/spf13/pflag#Value might work.
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.
No blockers
Issue: PGO-13
d13dd37
to
20fd95a
Compare
pgo show
,ha
, which provides thepatronictl list
command info when invoked.pgo show backup
andpgo show ha
to thepgo show
command.pgo show backup --output
Issue: PGO-13