Skip to content

oc policy can-i --list output is not parser friendly #15125

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

Merged
merged 2 commits into from
Aug 2, 2017
Merged

oc policy can-i --list output is not parser friendly #15125

merged 2 commits into from
Aug 2, 2017

Conversation

abstractj
Copy link

@abstractj abstractj commented Jul 10, 2017

@fabianofranz this fixes #11147 is just a rebase from the changes that @juanvallejo made.
He pretty much did all the hard work on it.

fixes #11147

@abstractj
Copy link
Author

@juanvallejo interesting. Jenkins is misbehaving, but looking at the console it does not seems related with your change :/

@@ -79,6 +83,7 @@ func NewCmdCanI(name, fullName string, f *clientcmd.Factory, out io.Writer) *cob
cmd.Flags().StringVar(&o.User, "user", o.User, "Check the specified action using this user instead of your user.")
cmd.Flags().StringSliceVar(&o.Groups, "groups", o.Groups, "Check the specified action using these groups instead of your groups.")

kcmdutil.AddPrinterFlags(cmd)
Copy link
Member

Choose a reason for hiding this comment

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

This adds a number of additional flags (--sort-by, --no-headers, etc). Do they all behave correctly?

Copy link
Author

Choose a reason for hiding this comment

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

@fabianofranz from what I tested manually, it does not crash, but the same time it takes no effect. I'm not sure if we should worry about it.

Copy link
Contributor

Choose a reason for hiding this comment

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

from what I tested manually, it does not crash, but the same time it takes no effect. I'm not sure if we should worry about it.

We would get this for free if we switch to using the HumanReadablePrinter :)

Copy link
Author

Choose a reason for hiding this comment

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

If you are both in agreement on it, why not!? Let's switch to this.

}

if o.Printer != nil {
return o.Printer.PrintObj(rulesReviewResult, o.Out)
}

writer := tabwriter.NewWriter(o.Out, tabwriterMinWidth, tabwriterWidth, tabwriterPadding, tabwriterPadChar, tabwriterFlags)
Copy link
Member

Choose a reason for hiding this comment

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

Would it make sense to get rid of this+4 lines and always rely on the printer, with the HumanReadablePrinter by default?

Copy link
Author

Choose a reason for hiding this comment

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

@fabianofranz not sure TBH. Maybe @juanvallejo can tell us more. One thing that I saw at the docs is the fact that HumanReadablePrinter is not threadsafe. Should we be concerned about it?

What would be the practical benefit of using it? Get rid of AddPrinterFlags ?

Copy link
Contributor

Choose a reason for hiding this comment

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

One thing that I saw at the docs is the fact that HumanReadablePrinter is not threadsafe. Should we be concerned about it?

No, not for this use-case in my opinion

What would be the practical benefit of using it? Get rid of AddPrinterFlags ?

We would get functionality for additional printer flags (no-headers, show-all, wide, ...)

Copy link
Contributor

@juanvallejo juanvallejo Jul 12, 2017

Choose a reason for hiding this comment

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

Would it make sense to get rid of this+4 lines and always rely on the printer, with the HumanReadablePrinter by default?

I agree makes sense, though I think we might have to add a handler here with the current printing behavior in DescribePolicyRule

Copy link
Author

Choose a reason for hiding this comment

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

@juanvallejo could you elaborate more? Looking at the code if we add that, that might affect DescribeRoleBinding too. Not sure if we want that.

Copy link
Contributor

Choose a reason for hiding this comment

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

could you elaborate more?

Sure, I was suggesting that we should add a new handler func (kind of like was done for buildConfigs, for example) that knows how to print a list of policy rules while taking human-readable printer options into account. We could re-use some of the code that now exists in DescribePolicyRule.

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, that looks like a good start

Copy link
Author

@abstractj abstractj Jul 18, 2017

Choose a reason for hiding this comment

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

@juanvallejo just updated the code https://github.com/abstractj/origin/commit/b6a235530ca969cb3a03e32f95a307c7c6a4abbb. But I feel like there's something missing, because it's not working :)

Some considerations:

  1. If we remove kcmdutil.AddPrinterFlags we lose --output. I believe that if that's the idea, might be necessary to add something like:
	cmd.Flags().StringVar(&o.Output, "output", o.Output, "YAML or JSON")

	output := kcmdutil.GetFlagString(cmd, "output")
	if len(output) > 0 {
		//print
	}
  1. The code duplicates the same code at DescribePolicyRule, should we remove this function? I guess not, but worth to check.

Copy link
Author

Choose a reason for hiding this comment

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

@fabianofranz fyi we've been discussing the changes here https://github.com/abstractj/origin/commit/b6a235530ca969cb3a03e32f95a307c7c6a4abbb#diff-06058d45973b9854e2a088207ab6ee7fR383. I haven't included it to this PR, because my changes atm will revert to the original state.

@fabianofranz
Copy link
Member

I'd also suggest adding a couple tests with --list --output=<foo> to test/cmd/authentication.sh, @abstractj there's a section for can-i tests there already, should be pretty straightforward. ;)

@abstractj
Copy link
Author

abstractj commented Jul 12, 2017

@fabianofranz sure, will look about how to add tests for it.

@abstractj
Copy link
Author

@juanvallejo @fabianofranz PR updated with tests. Not sure if they are consistent enough for this change, but please let me know if there's anything else that should be updated.

@@ -132,14 +130,15 @@ func (o *canIOptions) Complete(cmd *cobra.Command, f *clientcmd.Factory, args []

output := kcmdutil.GetFlagString(cmd, "output")
if len(output) > 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Did you mean to keep this conditional block here?

}

printer, err := f.PrinterForCommand(cmd, false, nil, printers.PrintOptions{})
Copy link
Contributor

Choose a reason for hiding this comment

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

you should handle this error


}

printer, err := f.PrinterForCommand(cmd, false, nil, printers.PrintOptions{})
Copy link
Contributor

Choose a reason for hiding this comment

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

@fabianofranz I have not yet tested flags like --sort-by with this PR;
@abstractj maybe we should handle options like no-headers here:

printers.PrintOptions{
    NoHeaders: kcmdutil.GetFlagBool(cmd, "no-headers"),
}

Also, -o name renders the output: <unknown>/<unknown>, although not sure if that might be related to this pr

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 554b0ff

@abstractj abstractj requested a review from juanvallejo July 21, 2017 17:32
@abstractj
Copy link
Author

@juanvallejo just updated the PR based on your comments. Regards to what you said:

@abstractj maybe we should handle options like no-headers here:

printers.PrintOptions{
    NoHeaders: kcmdutil.GetFlagBool(cmd, "no-headers"),
}
Also, -o name renders the output: <unknown>/<unknown>, although not sure if that might be related to this pr

I don't bother to do more changes related to this. I'm just afraid of we never reach an end, because you know, there's always more to improve. Anyways, whatever you guys decide is fine for me.

If you choose to open an enhancement, feel free to assign to me. Otherwise, let's iterate over this PR.

@juanvallejo
Copy link
Contributor

I don't bother to do more changes related to this. I'm just afraid of we never reach an end, because you know, there's always more to improve. Anyways, whatever you guys decide is fine for me.

I'd be okay with just changing AddPrinterFlags to kcmdutil.AddOutputFlags and maybe in a later revision considering adding support for additional flags; though will defer the final say on this to @fabianofranz

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/3407/) (Base Commit: e97ba37) (PR Branch Commit: 554b0ff)

@openshift-merge-robot openshift-merge-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 24, 2017
@openshift-merge-robot openshift-merge-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jul 27, 2017
@abstractj
Copy link
Author

/retest

@juanvallejo
Copy link
Contributor

juanvallejo commented Jul 27, 2017

you're not using this package anywhere in cani.go

@abstractj
Copy link
Author

/retest

@openshift-merge-robot openshift-merge-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 28, 2017
@abstractj
Copy link
Author

@juanvallejo green again!

@openshift-merge-robot openshift-merge-robot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 28, 2017
@0xmichalis 0xmichalis assigned juanvallejo and unassigned mfojtik and 0xmichalis Jul 29, 2017
juanvallejo and others added 2 commits July 31, 2017 09:21
Inclusion of printer handlers for oc policy. The goal is to permit
people to print the output in YAML or JSON by running:

oc policy can-i --list --output=yaml

Signed-off-by: Bruno Oliveira <[email protected]>
@pweil-
Copy link

pweil- commented Jul 31, 2017

@abstractj @fabianofranz @juanvallejo ok, let's go with AddOutputFlags for now to get what we need for the issue and a follow up issue to track adding other options is fine with me.

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Aug 1, 2017
@fabianofranz
Copy link
Member

/lgtm
/approve

@openshift-merge-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abstractj, fabianofranz

No associated issue. Update pull-request body to add a reference to an issue, or get approval with /approve no-issue

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

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 1, 2017
@enj
Copy link
Contributor

enj commented Aug 2, 2017

/test end_to_end

@openshift-merge-robot openshift-merge-robot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 2, 2017
@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue (batch tested with PRs 15512, 15582, 15125, 15590, 15593)

@openshift-merge-robot openshift-merge-robot merged commit 68da586 into openshift:master Aug 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

oc policy can-i --list output is not parser friendly.
10 participants