Wrong layout of driver-related commands in OSC-plugin spec

[Kyrylo Romanenko]

Driver commands in spec:

openstack baremetal driver show <driver_name>
openstack baremetal driver show properties <driver_name>
openstack baremetal driver show passthru <driver_name>
openstack baremetal driver list
openstack baremetal driver passthru <driver_name> <method>

This looks wrong, because all OSC command groups have layout like:
command subcommand aaa
command subcommand bbb
command subcommand ccc

Command layout should NOT be like this:
command subcommand
command subcommand aaa
command subcommand bbb

In this case OSC plugin commands style implementation will work by following way:
commands "baremetal driver show properties" and "baremetal driver show passthru" will be parsed as "baremetal driver show", and "properties" and "passthru" will be accepted like <driver_name> argument.

Driver-related section of OSC plugin spec:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironicclient-osc-plugin.html#openstack-baremetal-driver

This bug is blocker for implementation of baremetal driver OSC plugin commands:
https://review.openstack.org/#/c/350050/

[Dmitry Tantsur (divius)]

Please feel free to amend the spec:

openstack baremetal driver show <driver_name>
openstack baremetal driver properties show <driver_name>
openstack baremetal driver passthru show <driver_name>

or similar

[Kyrylo Romanenko (kromanenko)]

Possibly this is permissible layout. I have found such example of commands only in python-mistralclient:
https://github.com/openstack/python-mistralclient/blob/master/setup.cfg#L57-L59
https://github.com/openstack/python-mistralclient/blob/master/setup.cfg#L67-L69

Will look in it more.

[Dean Troyer (dtroyer)]

The first question to answer about OSC commands is 'what is the resource name?'

Are these really three different resources? Hint: don't think about how the API or the backend is implemented, think about what a user will know/see, particularly in the context of other OSC commands. Without knowing more about this, I would start with the following commands (in the same order as above):

openstack baremetal driver show <driver>
openstack baremetal driver show --properties <driver>
openstack baremetal driver show --passthrough <driver>

In this case '--properties' is an unfortunate choice because elsewhere in OSC --property is used for what many project call metadata attached to a resource.

[Kyrylo Romanenko (kromanenko)]

Change to spec for review and discussion: https://review.openstack.org/#/c/351140/

[Ruby Loo (rloo)]

https://review.openstack.org/#/c/351140/ has been merged. It proposed
    openstack baremetal driver show <driver>
    openstack baremetal driver properties show <driver>
    openstack baremetal driver passthru show <driver>
    openstack baremetal driver passthru call <driver> <method>

I think Dean has some good points though.

We should spell out passthrough (instead of passthru).

I think we should go with 'openstack baremetal driver show --properties <driver>'.

I'm not sure what to do with passthrough though.

1. we want to show (list) the passthroughs available for this driver:
a. openstack baremetal driver show --passthroughs <driver>
- implementation-wise, cliff is funky. One would use show.ShowOne for the parent class that implements 'openstack baremetal driver show', except that for passthroughs, it is a list/table of 5 columns, but show.ShowOne is hardcoded to show two columns, 'Field' and 'Value' :-(
b. openstack baremetal driver list --passthroughs <driver> : totally messes up 'openstack baremetal driver list' though
c. openstack baremetal driver passthrough list

2. we want to be able to invoke/execute/call a passthrough. In the following, <action> could be nothing, 'call', 'run', 'execute', 'invoke'
a. openstack baremetal driver <action> passthrough <driver> <passthrough-name>
- this follows the osc command structure
b. openstack baremetal driver passthrough <action> <driver> <passthrough-name>
-if we go with 1c, this seems more consistent.

I'm tempted to go with 1c and 2b, with <action> = execute.

[Mathieu Mitchell (mat128)]

I agree with 1c and 2b, with action being nothing.

``openstack baremetal driver passthrough agent_ipmitool lookup``

[Jay Faulkner (jason-oldos)]

I'm on board with 1c and 2b, although as I noted in IRC, I prefer keeping "passthru" as "thru" is a dictionary synonym for "through", and because of that I think we should be less keen on changing the client name to something different than the API endpoint.

[Jay Faulkner (jason-oldos)]

To be clear: passthru vs passthrough is a minor preference. If others care more than me, please don't let me hold up :)

[Ruby Loo (rloo)]

I think to satisfy the masses, we can provide both 'passthru' and 'passthrough' commands.

I forgot, we can't have 2b with a null action if we have 1c, because of the way the command line parsing is done. So how about
1c: 'openstack baremetal driver passthrough list'
2b: openstack baremetal driver passthrough call agent_ipmitool lookup

I've got a patch with those changes (among others): https://review.openstack.org/#/c/357505/

[Ruby Loo (rloo)]

There was dissent among the troops; people didn't like having two commands do the same thing. We ended up deciding to use 'passthru', not 'passthrough'. So:

1c: 'openstack baremetal driver passthru list'
2b: openstack baremetal driver passthru call agent_ipmitool lookup

The code change for this has merged (I forgot to link the patch to this). Here's the patch: https://review.openstack.org/#/c/350050/. A similar change was made for the node version too.