New sub-command to list access policy for a system

[Amit Saha]

I noticed that there is no sub-command to list the existing policy for a system, so
tried writing one [1]. My primary objective is to of course having it as a sub-command,
unless there was another reason other than time that it wasn't added earlier.

The second objective is to use it as the second example in our developer guide
to show how you expose controller methods and write a client to access it.

Example usage:

# bkr policy-list --system beaker-test-vm1 --hub http://localhost/bkr --username admin --password foobar
{
  "rules": [
    {
      "everybody": true,
      "permission": "control_system",
      "group": null,
      "id": 1,
      "user": null
    },
    {
      "everybody": true,
      "permission": "reserve",
      "group": null,
      "id": 4,
      "user": null
    }
  ],
  "possible_permissions": [
    {
      "value": "edit_policy",
. ..
. ..

The authentication bit is not required I suspect.

[1] http://paste.fedoraproject.org/41757/13800067/

Thoughts and suggestions welcome.

Best,
Amit.

[Dan Callaghan]

Excerpts from Amit Saha's message of 2013-09-24 17:17:22 +1000:
> I noticed that there is no sub-command to list the existing policy for a system, so
> tried writing one [1]. My primary objective is to of course having it as a sub-command,
> unless there was another reason other than time that it wasn't added earlier.
>
> The second objective is to use it as the second example in our developer guide
> to show how you expose controller methods and write a client to access it.
>
> Example usage:
>
> # bkr policy-list --system beaker-test-vm1 --hub http://localhost/bkr --username admin --password foobar
> {
>   "rules": [
>     {
>       "everybody": true,
>       "permission": "control_system",
>       "group": null,
>       "id": 1,
>       "user": null
>     },
>     {
>       "everybody": true,
>       "permission": "reserve",
>       "group": null,
>       "id": 4,
>       "user": null
>     }
>   ],
>   "possible_permissions": [
>     {
>       "value": "edit_policy",
> . ..
> . ..

I like it, my only suggestion would be to accept a --format option like 
the other commands. It would have --format=json for machine parsing, and 
a tabular/linear format that is friendlier for humans and grepping. 
Perhaps --format=text which spits out just a list of rules, one per 
line:

Group beakerdevs has permission edit_policy
    User asaha has permission reserve
    Everybody has permission control_system
> The authentication bit is not required I suspect.

Not sure what you mean... No reason to require authentication on the 
server side, no.

[Amit Saha]

----- Original Message -----
> From: "Dan Callaghan" 
> To: "Amit Saha" 
> Cc: "Beaker development" 
> Sent: Tuesday, September 24, 2013 5:32:52 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy for a	system
>
> Excerpts from Amit Saha's message of 2013-09-24 17:17:22 +1000:
> > I noticed that there is no sub-command to list the existing policy for a
> > system, so
> > tried writing one [1]. My primary objective is to of course having it as a
> > sub-command,
> > unless there was another reason other than time that it wasn't added
> > earlier.
> >
> > The second objective is to use it as the second example in our developer
> > guide
> > to show how you expose controller methods and write a client to access it.
> >
> > Example usage:
> >
> > # bkr policy-list --system beaker-test-vm1 --hub http://localhost/bkr
> > --username admin --password foobar
> > {
> >   "rules": [
> >     {
> >       "everybody": true,
> >       "permission": "control_system",
> >       "group": null,
> >       "id": 1,
> >       "user": null
> >     },
> >     {
> >       "everybody": true,
> >       "permission": "reserve",
> >       "group": null,
> >       "id": 4,
> >       "user": null
> >     }
> >   ],
> >   "possible_permissions": [
> >     {
> >       "value": "edit_policy",
> > . ..
> > . ..
>
> I like it, my only suggestion would be to accept a --format option like
> the other commands. It would have --format=json for machine parsing, and
> a tabular/linear format that is friendlier for humans and grepping.
> Perhaps --format=text which spits out just a list of rules, one per
> line:
> Group beakerdevs has permission edit_policy
> User asaha has permission reserve
> Everybody has permission control_system

Thanks. Yes, I will try to add that along with a test.
> > The authentication bit is not required I suspect.
>
> Not sure what you mean... No reason to require authentication on the
> server side, no.

Yes, that's what I meant. The command line arguments --username and --password
 are superfluous.

Best,
Amit.

[Amit Saha]

----- Original Message -----
> From: "Amit Saha" 
> To: "Beaker development" 
> Sent: Tuesday, September 24, 2013 5:38:48 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy for	a	system
>
> ----- Original Message -----
> > From: "Dan Callaghan" 
> > To: "Amit Saha" 
> > Cc: "Beaker development" 
> > Sent: Tuesday, September 24, 2013 5:32:52 PM
> > Subject: Re: [Beaker-devel] New sub-command to list access policy for a
> >    system
> >
> > Excerpts from Amit Saha's message of 2013-09-24 17:17:22 +1000:
> > > I noticed that there is no sub-command to list the existing policy for a
> > > system, so
> > > tried writing one [1]. My primary objective is to of course having it as
> > > a
> > > sub-command,
> > > unless there was another reason other than time that it wasn't added
> > > earlier.
> > >
> > > The second objective is to use it as the second example in our developer
> > > guide
> > > to show how you expose controller methods and write a client to access
> > > it.
> > >
> > > Example usage:
> > >
> > > # bkr policy-list --system beaker-test-vm1 --hub http://localhost/bkr
> > > --username admin --password foobar
> > > {
> > >   "rules": [
> > >     {
> > >       "everybody": true,
> > >       "permission": "control_system",
> > >       "group": null,
> > >       "id": 1,
> > >       "user": null
> > >     },
> > >     {
> > >       "everybody": true,
> > >       "permission": "reserve",
> > >       "group": null,
> > >       "id": 4,
> > >       "user": null
> > >     }
> > >   ],
> > >   "possible_permissions": [
> > >     {
> > >       "value": "edit_policy",
> > > . ..
> > > . ..
> >
> > I like it, my only suggestion would be to accept a --format option like
> > the other commands. It would have --format=json for machine parsing, and
> > a tabular/linear format that is friendlier for humans and grepping.
> > Perhaps --format=text which spits out just a list of rules, one per
> > line:
> > Group beakerdevs has permission edit_policy
> > User asaha has permission reserve
> > Everybody has permission control_system

Considering that the user/group names can and will most likely vary,
I used PrettyTable [1] to print the rules (when invoked with --format=list).
Example:

+------+-------+--------+----------------+
| Rule |  User | Group  |   Permission   |
+------+-------+--------+----------------+
|  1   | user7 |  None  |  edit_system   |
|  2   | user8 |  None  | control_system |
|  3   |  None | group9 | control_system |
+------+-------+--------+----------------+

The patch is here [2].

[1] https://pypi.python.org/pypi/PrettyTable/ (Already available in RHEL 6 and Fedora repositories)
[2] http://gerrit.beaker-project.org/#/c/2293/

-Amit.

[Amit Saha]

> Considering that the user/group names can and will most likely vary,

(In length and hence to have consistent output).
> I used PrettyTable [1] to print the rules (when invoked with --format=list).
> Example:
>
> +------+-------+--------+----------------+
> | Rule |  User | Group  |   Permission   |
> +------+-------+--------+----------------+
> |  1   | user7 |  None  |  edit_system   |
> |  2   | user8 |  None  | control_system |
> |  3   |  None | group9 | control_system |
> +------+-------+--------+----------------+
>
> The patch is here [2].
>
> [1] https://pypi.python.org/pypi/PrettyTable/ (Already available in RHEL 6
> and Fedora repositories)
> [2] http://gerrit.beaker-project.org/#/c/2293/
>
> -Amit.
> _______________________________________________
> Beaker-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel

[Dan Callaghan]

Excerpts from Amit Saha's message of 2013-09-25 15:24:30 +1000:
> > > I like it, my only suggestion would be to accept a --format option 
> > > like
> > > the other commands. It would have --format=json for machine parsing, and
> > > a tabular/linear format that is friendlier for humans and grepping.
> > > Perhaps --format=text which spits out just a list of rules, one per
> > > line:
> > > Group beakerdevs has permission edit_policy
> > > User asaha has permission reserve
> > > Everybody has permission control_system
>
> Considering that the user/group names can and will most likely vary,
> I used PrettyTable [1] to print the rules (when invoked with --format=list).
> Example:
>
> +------+-------+--------+----------------+
> | Rule |  User | Group  |   Permission   |
> +------+-------+--------+----------------+
> |  1   | user7 |  None  |  edit_system   |
> |  2   | user8 |  None  | control_system |
> |  3   |  None | group9 | control_system |
> +------+-------+--------+----------------+
>
> The patch is here [2].

PrettyTable sounds nifty, I'd never heard of it before.

I'm not sure a table is a good way to represent the rules though. A rule 
applies either to a particular user, a particular group, or everybody. 
The table view doesn't really make that easy to see (especially for the 
"everybody" case) which is why I had suggested just the plain listing of 
rules.

[Amit Saha]

----- Original Message -----
> From: "Dan Callaghan" 
> To: "Amit Saha" 
> Cc: "Beaker development" 
> Sent: Wednesday, September 25, 2013 3:42:53 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy for a	system
>
> Excerpts from Amit Saha's message of 2013-09-25 15:24:30 +1000:
> > > > I like it, my only suggestion would be to accept a --format option
> > > > like
> > > > the other commands. It would have --format=json for machine parsing,
> > > > and
> > > > a tabular/linear format that is friendlier for humans and grepping.
> > > > Perhaps --format=text which spits out just a list of rules, one per
> > > > line:
> > > > Group beakerdevs has permission edit_policy
> > > > User asaha has permission reserve
> > > > Everybody has permission control_system
> >
> > Considering that the user/group names can and will most likely vary,
> > I used PrettyTable [1] to print the rules (when invoked with
> > --format=list).
> > Example:
> >
> > +------+-------+--------+----------------+
> > | Rule |  User | Group  |   Permission   |
> > +------+-------+--------+----------------+
> > |  1   | user7 |  None  |  edit_system   |
> > |  2   | user8 |  None  | control_system |
> > |  3   |  None | group9 | control_system |
> > +------+-------+--------+----------------+
> >
> > The patch is here [2].
>
> PrettyTable sounds nifty, I'd never heard of it before.
>
> I'm not sure a table is a good way to represent the rules though. A rule
> applies either to a particular user, a particular group, or everybody.
> The table view doesn't really make that easy to see (especially for the
> "everybody" case) which is why I had suggested just the plain listing of
> rules.

I am going to push this a little further :-).

I made some changes and now the output is:

+------+----------------+--------+---------+-----------+
| Rule |   Permission   |  User  |  Group  | Everybody |
+------+----------------+--------+---------+-----------+
|  1   |  edit_system   | user10 |    X    |     X     |
|  2   | control_system | user11 |    X    |     X     |
|  3   | control_system |   X    | group12 |     X     |
+------+----------------+--------+---------+-----------+

How do you find it?

[Nick Coghlan]

On 09/25/2013 04:25 PM, Amit Saha wrote:
> ----- Original Message -----
> > From: "Dan Callaghan" 
> > PrettyTable sounds nifty, I'd never heard of it before.

Indeed, would have been handy back when I was working on the client for
PulpDist.
> > I'm not sure a table is a good way to represent the rules though. A rule
> > applies either to a particular user, a particular group, or everybody.
> > The table view doesn't really make that easy to see (especially for the
> > "everybody" case) which is why I had suggested just the plain listing of
> > rules.
>
> I am going to push this a little further :-).
>
> I made some changes and now the output is:
>
> +------+----------------+--------+---------+-----------+
> | Rule |   Permission   |  User  |  Group  | Everybody |
> +------+----------------+--------+---------+-----------+
> |  1   |  edit_system   | user10 |    X    |     X     |
> |  2   | control_system | user11 |    X    |     X     |
> |  3   | control_system |   X    | group12 |     X     |
> +------+----------------+--------+---------+-----------+
>
> How do you find it?

So, ordered by permission and displaying "yes" in the Everybody column
when neither user nor group is specified?

Sounds reasonable to me.

We may want a "show-permissions" command, too. Similar to the one liner
"What are *my* permissions?" we were discussing for the web UI.

Cheers,
Nick.

[Amit Saha]

----- Original Message -----
> From: "Nick Coghlan" 
> To: [e-mail]
> Sent: Wednesday, September 25, 2013 5:09:03 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy for	a	system
>
> On 09/25/2013 04:25 PM, Amit Saha wrote:
> > ----- Original Message -----
> > > From: "Dan Callaghan" 
> > > PrettyTable sounds nifty, I'd never heard of it before.
>
> Indeed, would have been handy back when I was working on the client for
> PulpDist.

That is where, a lot of the time this morning went into,  but it does indeed 
look like a good find. And we don't need to resort to .format()'s mini-language 
to get it right.
> > > I'm not sure a table is a good way to represent the rules though. A rule
> > > applies either to a particular user, a particular group, or everybody.
> > > The table view doesn't really make that easy to see (especially for the
> > > "everybody" case) which is why I had suggested just the plain listing of
> > > rules.
> >
> > I am going to push this a little further :-).
> >
> > I made some changes and now the output is:
> >
> > +------+----------------+--------+---------+-----------+
> > | Rule |   Permission   |  User  |  Group  | Everybody |
> > +------+----------------+--------+---------+-----------+
> > |  1   |  edit_system   | user10 |    X    |     X     |
> > |  2   | control_system | user11 |    X    |     X     |
> > |  3   | control_system |   X    | group12 |     X     |
> > +------+----------------+--------+---------+-----------+
> >
> > How do you find it?
>
> So, ordered by permission and displaying "yes" in the Everybody column
> when neither user nor group is specified?
>
> Sounds reasonable to me.

Not exactly what I have done, but yes certainly can be done.
PrettyTable can even sort by a header [1].
> We may want a "show-permissions" command, too. Similar to the one liner
> "What are *my* permissions?" we were discussing for the web UI.

Sure, sounds like a good idea.

[1] http://code.google.com/p/prettytable/wiki/Tutorial#Sorting_tables

Best,
Amit.

[Amit Saha]

----- Original Message -----
> From: "Amit Saha" 
> To: "Beaker development" 
> Sent: Wednesday, September 25, 2013 5:31:57 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy	for	a	system
>
> ----- Original Message -----
> > From: "Nick Coghlan" 
> > To: [e-mail]
> > Sent: Wednesday, September 25, 2013 5:09:03 PM
> > Subject: Re: [Beaker-devel] New sub-command to list access policy for	a
> >    system
> >
> > On 09/25/2013 04:25 PM, Amit Saha wrote:
> > > ----- Original Message -----
> > > > From: "Dan Callaghan" 
> > > > PrettyTable sounds nifty, I'd never heard of it before.
> >
> > Indeed, would have been handy back when I was working on the client for
> > PulpDist.
>
> That is where, a lot of the time this morning went into,  but it does indeed
> look like a good find. And we don't need to resort to .format()'s
> mini-language
> to get it right.
> > > > I'm not sure a table is a good way to represent the rules though. A rule
> > > > applies either to a particular user, a particular group, or everybody.
> > > > The table view doesn't really make that easy to see (especially for the
> > > > "everybody" case) which is why I had suggested just the plain listing of
> > > > rules.
> > >
> > > I am going to push this a little further :-).
> > >
> > > I made some changes and now the output is:
> > >
> > > +------+----------------+--------+---------+-----------+
> > > | Rule |   Permission   |  User  |  Group  | Everybody |
> > > +------+----------------+--------+---------+-----------+
> > > |  1   |  edit_system   | user10 |    X    |     X     |
> > > |  2   | control_system | user11 |    X    |     X     |
> > > |  3   | control_system |   X    | group12 |     X     |
> > > +------+----------------+--------+---------+-----------+
> > >
> > > How do you find it?
> >
> > So, ordered by permission and displaying "yes" in the Everybody column
> > when neither user nor group is specified?

One point to note here is that ordering by permission will most likely
cause the Rule numbers to go haywire. Do we really want that? On the other hand,
I understand that sorting by Permissions will "group" them as well.

Shall I drop the rule number column?

[Nick Coghlan]

On 09/26/2013 02:22 PM, Amit Saha wrote:
> One point to note here is that ordering by permission will most likely
> cause the Rule numbers to go haywire. Do we really want that? On the other hand,
> I understand that sorting by Permissions will "group" them as well.
>
> Shall I drop the rule number column?

Yes, I think so. Rules are content addressed in the interface anyway
(i.e. you revoke a permission by describing it, not by giving the rule ID).

Cheers,
Nick.

[Amit Saha]

----- Original Message -----
> From: "Nick Coghlan" 
> To: [e-mail]
> Sent: Thursday, September 26, 2013 3:15:06 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy for a	system
>
> On 09/26/2013 02:22 PM, Amit Saha wrote:
> > One point to note here is that ordering by permission will most likely
> > cause the Rule numbers to go haywire. Do we really want that? On the other
> > hand,
> > I understand that sorting by Permissions will "group" them as well.
> >
> > Shall I drop the rule number column?
>
> Yes, I think so. Rules are content addressed in the interface anyway
> (i.e. you revoke a permission by describing it, not by giving the rule ID).

Sounds good. Done that. [1]

[1] http://gerrit.beaker-project.org/#/c/2293/3

[Amit Saha]

----- Original Message -----
> From: "Nick Coghlan" 
> To: [e-mail]
> Sent: Wednesday, September 25, 2013 5:09:03 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy for	a	system
>
> On 09/25/2013 04:25 PM, Amit Saha wrote:
> > ----- Original Message -----
> > > From: "Dan Callaghan" 
> > > PrettyTable sounds nifty, I'd never heard of it before.
>
> Indeed, would have been handy back when I was working on the client for
> PulpDist.
> > > I'm not sure a table is a good way to represent the rules though. A rule
> > > applies either to a particular user, a particular group, or everybody.
> > > The table view doesn't really make that easy to see (especially for the
> > > "everybody" case) which is why I had suggested just the plain listing of
> > > rules.
> >
> > I am going to push this a little further :-).
> >
> > I made some changes and now the output is:
> >
> > +------+----------------+--------+---------+-----------+
> > | Rule |   Permission   |  User  |  Group  | Everybody |
> > +------+----------------+--------+---------+-----------+
> > |  1   |  edit_system   | user10 |    X    |     X     |
> > |  2   | control_system | user11 |    X    |     X     |
> > |  3   | control_system |   X    | group12 |     X     |
> > +------+----------------+--------+---------+-----------+
> >
> > How do you find it?
>
> So, ordered by permission and displaying "yes" in the Everybody column
> when neither user nor group is specified?
>
> Sounds reasonable to me.
>
> We may want a "show-permissions" command, too. Similar to the one liner
> "What are *my* permissions?" we were discussing for the web UI.

Did you mean "show what permissions I have for this system?" If so,
how about adding a '--mine' switch to the list-policy subcommand?

Best,
Amit.

[Nick Coghlan]

On 10/03/2013 01:10 PM, Amit Saha wrote:
> > We may want a "show-permissions" command, too. Similar to the one liner
> > "What are *my* permissions?" we were discussing for the web UI.
>
> Did you mean "show what permissions I have for this system?" If so,
> how about adding a '--mine' switch to the list-policy subcommand?

I like it. Not only would that show what permissions the user has
(anything listed in the permissions column), but also *how* they're
acquiring them.

Hmm, for admin purposes similar filtering for arbitrary users and groups
could be helpful.

Cheers,
Nick.

[Nick Coghlan]

On 10/03/2013 01:29 PM, Nick Coghlan wrote:
> On 10/03/2013 01:10 PM, Amit Saha wrote:
> > Did you mean "show what permissions I have for this system?" If so,
> > how about adding a '--mine' switch to the list-policy subcommand?
>
> I like it. Not only would that show what permissions the user has
> (anything listed in the permissions column), but also *how* they're
> acquiring them.
>
> Hmm, for admin purposes similar filtering for arbitrary users and groups
> could be helpful.

I forgot to say - still worth making that a separate patch so it can be
reviewed separately from the base command.

Cheers,
Nick.

[Amit Saha]

----- Original Message -----
> From: "Nick Coghlan" 
> To: [e-mail]
> Sent: Thursday, October 3, 2013 1:31:26 PM
> Subject: Re: [Beaker-devel] New sub-command to list access policy	for	a	system
>
> On 10/03/2013 01:29 PM, Nick Coghlan wrote:
> > On 10/03/2013 01:10 PM, Amit Saha wrote:
> > > Did you mean "show what permissions I have for this system?" If so,
> > > how about adding a '--mine' switch to the list-policy subcommand?
> >
> > I like it. Not only would that show what permissions the user has
> > (anything listed in the permissions column), but also *how* they're
> > acquiring them.
> >
> > Hmm, for admin purposes similar filtering for arbitrary users and groups
> > could be helpful.
>
> I forgot to say - still worth making that a separate patch so it can be
> reviewed separately from the base command.

Yes, that was my thought too. Filed a bz [1] to track it.
Please add a comment if the suggested use cases and interface
needs  modifications.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1014899

Best,
Amit.

[Amit Saha]

----- Original Message -----
> From: "Amit Saha" 
> To: "Beaker development" 
> Sent: Thursday, October 3, 2013 2:50:31 PM
> Subject: Re: [Beaker-devel] New sub-command to list access	policy	for	a	system
>
> ----- Original Message -----
> > From: "Nick Coghlan" 
> > To: [e-mail]
> > Sent: Thursday, October 3, 2013 1:31:26 PM
> > Subject: Re: [Beaker-devel] New sub-command to list access policy	for	a
> >    system
> >
> > On 10/03/2013 01:29 PM, Nick Coghlan wrote:
> > > On 10/03/2013 01:10 PM, Amit Saha wrote:
> > > > Did you mean "show what permissions I have for this system?" If so,
> > > > how about adding a '--mine' switch to the list-policy subcommand?
> > >
> > > I like it. Not only would that show what permissions the user has
> > > (anything listed in the permissions column), but also *how* they're
> > > acquiring them.
> > >
> > > Hmm, for admin purposes similar filtering for arbitrary users and groups
> > > could be helpful.
> >
> > I forgot to say - still worth making that a separate patch so it can be
> > reviewed separately from the base command.
>
> Yes, that was my thought too. Filed a bz [1] to track it.
> Please add a comment if the suggested use cases and interface
> needs  modifications.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1014899

Uploaded a patch here [1]. As of now, only one filtering criteria is allowed.

[1] http://gerrit.beaker-project.org/#/c/2573/

Best,
Amit.