Open Stack

Thanks for the list, Sam. I've left some comments inline...

On Tue, Nov 10, 2015 at 4:19 AM, Sam Betts (sambetts) <sambetts at cisco.com>
wrote:

> So you would end up with a set of commands that look like this:
>
> Openstack baremetal [node/driver/chassis] list
>

will this command support filtering, similar to our CLI ?


> Openstack baremetal port list [—node uuid] <— replicate node-port-list
>

> Openstack baremetal [node/port/driver] show UUID
>

>
Openstack baremetal chassis show [—nodes] UUID  <— replicate
> chassis-node-list
>

this one seems off to me. "show" commands should be displaying the details
of the requested object, not listing a summarized set of objects. Instead
of "chassis show --nodes UUID", I think the command should be "node list
--chassis uuid", which also matches the option to "port list --node uuid".


>
> Openstack baremetal [node/chassis/port] create
> Openstack baremetal [node/chassis/port] update UUID
> Openstack baremetal [node/chassis/port] delete UUID
>

all seem good


>
> Openstack baremetal [node/chassis] provide UUID
> Openstack baremetal [node/chassis] activate UUID
> Openstack baremetal [node/chassis] rebuild UUID
> Openstack baremetal [node/chassis] inspect UUID
> Openstack baremetal [node/chassis] manage UUID
> Openstack baremetal [node/chassis] abort UUID
> Openstack baremetal [node/chassis] boot UUID
> Openstack baremetal [node/chassis] shutdown UUID
> Openstack baremetal [node/chassis] reboot UUID
>

Firstly, I would suggest removing the "chassis" noun here, at least until
we sort out how we want to handle grouping within the service. Right now,
"chassis" resources do not support any verbs - they can only be created and
deleted, and used as a loose logical grouping of nodes.

Secondly, I would change some of these verbs as follows:
  s/activate/deploy/ - because the resulting state transitions will show as
"deploying", etc
  s/boot/poweron/ && s/shutdown/poweroff/ - because that is a more accurate
description of what will be done, and it moves away from the "nova boot"
command, which is completely different.


>
> Openstack baremetal node maintain [—done] UUID
>

I would rename this option as well, but I'm not sure to what. The action
represented by this verb is not a lengthy process (as could be implied by
the verb "maintain", like, "go do some maintenance on it"). This is merely
the changing of a flag within the state of the resource, which instructs
ironic-conductor to leave that node alone without changing any other state,
so perhaps a more appropriate verb would be "ignore" or "exclude"... eg,
"Openstack baremetal node [exclude|include] UUID"



> Openstack baremetal node console [—enable, —disable] UUID <— With no
> parameters this acts like node-get-console, otherwise acts
> like node-set-console-mode
> Openstack baremetal node boot-device [—supported, —PXE, —CDROM, etc] UUID
> <— With no parameters this acts like node-get-boot-device, —supported
> makes it act like node-get-supported-boot-devices, and with a type of boot
> device passed in it’ll act like node-set-boot-device
>
> Openstack baremetal [node/driver] passthru
>

> WDYT? I think I’ve covered most of what exists in the Ironic CLI
> currently.
>
> Sam
>
> From: "Haomeng, Wang" <wanghaomeng at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, 10 November 2015 11:41
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient
> command for provision action
>
> Hi Sam,
>
> Yes, I understand your format is：
>
> #openstack baremetal <action> <uuid>
>
> so these can cover all 'node' operations however if we want to cover
> support port/chassis/driver and more ironic resources, so how about below
> proposal?
>
> #openstack baremetal <resource/target> <action> <uuid>
>
> The resource/target can be one item in following list:
>
> node
> port
> chassis
> driver
> ...
>
> Make sense?
>
>
>
>
> On Tue, Nov 10, 2015 at 7:25 PM, Sam Betts (sambetts) <sambetts at cisco.com>
> wrote:
>
>> Openstack baremetal provision provide or —provide Just doesn’t feel right
>> to me, it feels like I am typing more that I need to and it feels like I’m
>> telling it to do the same action twice.
>>
>> I would much rather see:
>>
>> Openstack baremetal provide UUID
>> Openstack baremetal activate UUID
>> Openstack baremetal delete UUID
>> Openstack baremetal rebuild UUID
>> Openstack baremetal inspect UUID
>> Openstack baremetal manage UUID
>> Openstack baremetal abort UUID
>>
>> And for power:
>>
>> Openstack baremetal boot UUID
>> Openstack beremetal shutdown UUID
>> Openstack baremetal reboot UUID
>>
>> WDYT?
>>
>> Sam
>>
>> From: "Haomeng, Wang" <wanghaomeng at gmail.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Tuesday, 10 November 2015 10:49
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient
>> command for provision action
>>
>>
>> How about below format?
>>
>> #openstack baremetal <resource/target> <action> <uuid>
>>
>> Example:
>>
>> #openstack baremetal provision provide <UUID>
>> #openstack baremetal power on/off  <UUID>
>>
>> I think it is easy to understand and remember:)
>>
>>
>>
>> On Tue, Nov 10, 2015 at 6:17 PM, Pavlo Shchelokovskyy <
>> pshchelokovskyy at mirantis.com> wrote:
>>
>>> Hi,
>>> I like the last variant by Lucas, and agree we need to ensure the CLI
>>> interface is consistent between power and provision commands.
>>>
>>> Best regards,
>>>
>>>
>>> On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes <
>>> lucasagomes at gmail.com> wrote:
>>>
>>>> > It's still not 100% consistent, "power" is a noun, "provision" is a
>>>> verb.
>>>> > Not sure it matters, though, adding OSC folks so that they can weigh
>>>> in.
>>>> >
>>>>
>>>> "provision" can also be a noun [1]. But since the OSC syntax suggest
>>>> having a verb we could have something like:
>>>>
>>>> $ openstack baremetal set power --on | --off <UUID>
>>>> $ openstack baremetal set provision --provide | --active | ... <UUID>
>>>>
>>>> [1] http://www.thefreedictionary.com/provision
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> --
>>> Dr. Pavlo Shchelokovskyy
>>> Senior Software Engineer
>>> Mirantis Inc
>>> www.mirantis.com
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151117/3a801f05/attachment.html>