-
Notifications
You must be signed in to change notification settings - Fork 104
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
Package List (Parameters | Tasks | Plans) #1223
Conversation
… to add a number of other list types for operators Signed-off-by: Ken Sipe <kensipe@gmail.com>
Signed-off-by: Ken Sipe <kensipe@gmail.com>
Signed-off-by: Ken Sipe <kensipe@gmail.com>
needs tests otherwise good to go |
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.
Love the rename of the command 👏 much more consistent now. We should not forget to mention it as breaking change though.
I have couple of issues with this:
- I don't really understand the use case for the tasks command. As operator I cannot invoke tasks, as developer, I am editing the yaml so why would I list it through CLI when I can just directly open the yaml?
- I think the plans list should probably use tree view (just a suggestion)? I think using something like "github.com/xlab/treeprint" as in plan_status would be much nicer. Or we could just list plans without phases?
- I think the PR should reference an issue that should be in this iteration with meaningful description. If I remember correctly you were the one proposing everyone follows this :-)
- we need tests
plus the comments I had inline :-)
Signed-off-by: Ken Sipe <kensipe@gmail.com>
@alenkacz pushed updates for basic changes... I love the treeprint idea a lot. I will work on that next. regarding task list and desire to have it... I'm thinking of 2 users:
The question is: what does this opaque operator named x (mysql) do? what does it consist of? It is a reasonable argument that all you will get is a list of tasks with a list of template files.... but hopefully the naming of these things will be valuable... or perhaps we add an output for a file for viewing. |
LOVE the tree view! thanks @alenkacz ! |
Signed-off-by: Ken Sipe <kensipe@gmail.com>
Signed-off-by: Ken Sipe <kensipe@gmail.com>
Signed-off-by: Ken Sipe <kensipe@gmail.com>
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.
Love the tree view and cmd consistency! Left a few nits, but nothing critical.
@@ -0,0 +1,11 @@ | |||
plans |
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 like golden files but this seems to be too small to be one. wdyt about putting it into a multiline var in the test above? Same for the other two golden files below.
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 actually like this one a lot. it is a great output example that could be referenced via documentation (when using asciidoc). It is also easy for a developer to "see" what the output is intended to be.
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.
Hm, it's not exactly YAML files so that they absolutely must be referenced to stay consistent with the codebase. And a developer can "see" them even better if they're in the same test file, where they're used. But I don't feel too strongly about it so if you insist 🤷♂
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.
👍 for referencing these files in our documentation -- is there already a docs PR for this feature?
Signed-off-by: Ken Sipe <kensipe@gmail.com>
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.
🚢
concerns addressed and it isn't clear if she will return
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.
Thanks, this is a great addition, awesome to have these consistent set of subcommands to investigate operators.
My comments are mostly nits or small corrections, overall this looks great!
@@ -0,0 +1,11 @@ | |||
plans |
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.
👍 for referencing these files in our documentation -- is there already a docs PR for this feature?
} | ||
|
||
func sortedPlanNames(pf *packages.Files) []string { | ||
planNames := make([]string, 0, len(pf.Operator.Plans)) |
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.
sort.Strings
also calls sort.Sort
which is using interface{}
. So
sort.Sort(funk.Keys(pf.Operator.Plans))
would do the same.
} | ||
|
||
f := cmd.Flags() | ||
f.StringVar(&lc.RepoName, "repo", "", "Name of repository configuration to use. (default defined by context)") |
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.
Not yours, more a general question: Given that repo
and version
are variables shared by all these subcommands, is it possible in cobra
to "inherit" them here so that they don't have to be defined again for every subcommand?
|
||
gp := filepath.Join("testdata", file+".golden") | ||
|
||
if *updateGolden { |
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.
Probably not yours, but why would we update files in a test? Especially if it's the file we're testing against?
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 is to easy the burden on "known" output changes... it's a pretty standard technique
Co-Authored-By: Jan Schlicht <jan@d2iq.com>
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.
LGTM!
Signed-off-by: Ken Sipe <kensipe@gmail.com>
Co-authored-by: Jan Schlicht <jan.schlicht+gh@gmail.com> Signed-off-by: Ken Sipe <kensipe@gmail.com> Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>
What this PR does / why we need it:
Consolidating "list" as a verb under "package". Instead of
kudo package params list
, this PR changes tokudo package list parameters
and addskudo package list tasks
andkudo package list plans
.This CLI utility functions are useful when:
Tasks
** Plans **
or
** Parameters **
Fixes #