Re: [openstack-dev] [ironic] should we provide 'ironic node-list --chassis' and 'ironic port-list --node' commands?

2016-09-12 Thread Loo, Ruby 
Hi,

Vlad was the only one that was luke-warm in favour of 'ironic node-list 
--chassis'. Since I haven't received any positive, enthusiastic comment about 
wanting it, I don't think it is worth spending any more time pursuing it.

'openstack baremetal node list --chassis' does exist though (in 1.7.0 [1]).

--ruby

[1] http://docs.openstack.org/releasenotes/python-ironicclient/newton.html


On 2016-08-30, 11:57 AM, "Vladyslav Drok" 
> wrote:

The ironic node-list --chassis seems to be easier to understand for me. I've 
commented on one of the patches that maybe we should deprecate the 
chassis-node-list if we add this, but then, the deprecation is slow, we have 
some functional tests already... Having two commands kind of reflects the 
duplication in our API, where we can do /chassis//nodes and 
/nodes?chassis_uuid=, so maybe having both of them is fine.

Vlad

On Mon, Aug 29, 2016 at 7:22 PM, Loo, Ruby 
> wrote:
Hi,

While working on the openstackclient plugin commands for ironic, I was thinking 
about the equivalents for 'ironic chassis-node-list' (nodes that are part of 
specified chassis) and 'ironic-node-port-list' (ports that are part of 
specified node). It didn't make sense to me to have an 'openstack baremetal 
chassis node list', since a 'chassis' and a 'node' are two different objects in 
osc lingo and we already have 'openstack baremetal chassis xx' and 'openstack 
baremetal node yy' commands. Furthermore, our REST API supports 'GET 
/v1/nodes?chassis=c1' and 'GET /v1/ports?node=n1'.

So I proposed 'openstack baremetal node list --chassis' and 'openstack 
baremetal port list --node' [1]. To implement this, I need to enhance our 
corresponding python APIs. The question I have is whether we want to only 
enhance the python API, or also provide 'ironic node-list --chassis' and 
'ironic port-list --node' commands. The latter is being proposed [2] and coded 
at [3]. Doing this would mean two different ironic CLIs to do the same thing, 
but also provide a more obvious 1:1 correspondence between ironic & osc 
commands, and between ironic CLI and python API.

Thoughts?

It'd be great if we could decide in the next day or so, in order to get the 
osc-related commands into the client this week for the Newton release.

--ruby

[1] 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/ironicclient-osc-plugin.html#openstack-baremetal-node
[2] https://launchpad.net/bugs/1616242
[3] https://review.openstack.org/#/c/359520/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] should we provide 'ironic node-list --chassis' and 'ironic port-list --node' commands?

2016-08-30 Thread Vladyslav Drok 
The ironic node-list --chassis seems to be easier to understand for me.
I've commented on one of the patches that maybe we should deprecate the
chassis-node-list if we add this, but then, the deprecation is slow, we
have some functional tests already... Having two commands kind of reflects
the duplication in our API, where we can do /chassis//nodes and
/nodes?chassis_uuid=, so maybe having both of them is fine.

Vlad

On Mon, Aug 29, 2016 at 7:22 PM, Loo, Ruby  wrote:

> Hi,
>
>
>
> While working on the openstackclient plugin commands for ironic, I was
> thinking about the equivalents for 'ironic chassis-node-list' (nodes that
> are part of specified chassis) and 'ironic-node-port-list' (ports that are
> part of specified node). It didn't make sense to me to have an 'openstack
> baremetal chassis node list', since a 'chassis' and a 'node' are two
> different objects in osc lingo and we already have 'openstack baremetal
> chassis xx' and 'openstack baremetal node yy' commands. Furthermore, our
> REST API supports 'GET /v1/nodes?chassis=c1' and 'GET /v1/ports?node=n1'.
>
>
>
> So I proposed 'openstack baremetal node list --chassis' and 'openstack
> baremetal port list --node' [1]. To implement this, I need to enhance our
> corresponding python APIs. The question I have is whether we want to only
> enhance the python API, or also provide 'ironic node-list --chassis' and
> 'ironic port-list --node' commands. The latter is being proposed [2] and
> coded at [3]. Doing this would mean two different ironic CLIs to do the
> same thing, but also provide a more obvious 1:1 correspondence between
> ironic & osc commands, and between ironic CLI and python API.
>
>
>
> Thoughts?
>
>
>
> It'd be great if we could decide in the next day or so, in order to get
> the osc-related commands into the client this week for the Newton release.
>
>
>
> --ruby
>
>
>
> [1] http://specs.openstack.org/openstack/ironic-specs/specs/
> approved/ironicclient-osc-plugin.html#openstack-baremetal-node
>
> [2] https://launchpad.net/bugs/1616242
>
> [3] https://review.openstack.org/#/c/359520/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] should we provide 'ironic node-list --chassis' and 'ironic port-list --node' commands?

2016-08-29 Thread Loo, Ruby 
Hi,

While working on the openstackclient plugin commands for ironic, I was thinking 
about the equivalents for 'ironic chassis-node-list' (nodes that are part of 
specified chassis) and 'ironic-node-port-list' (ports that are part of 
specified node). It didn't make sense to me to have an 'openstack baremetal 
chassis node list', since a 'chassis' and a 'node' are two different objects in 
osc lingo and we already have 'openstack baremetal chassis xx' and 'openstack 
baremetal node yy' commands. Furthermore, our REST API supports 'GET 
/v1/nodes?chassis=c1' and 'GET /v1/ports?node=n1'.

So I proposed 'openstack baremetal node list --chassis' and 'openstack 
baremetal port list --node' [1]. To implement this, I need to enhance our 
corresponding python APIs. The question I have is whether we want to only 
enhance the python API, or also provide 'ironic node-list --chassis' and 
'ironic port-list --node' commands. The latter is being proposed [2] and coded 
at [3]. Doing this would mean two different ironic CLIs to do the same thing, 
but also provide a more obvious 1:1 correspondence between ironic & osc 
commands, and between ironic CLI and python API.

Thoughts?

It'd be great if we could decide in the next day or so, in order to get the 
osc-related commands into the client this week for the Newton release.

--ruby

[1] 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/ironicclient-osc-plugin.html#openstack-baremetal-node
[2] https://launchpad.net/bugs/1616242
[3] https://review.openstack.org/#/c/359520/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev