settingsLogin | Registersettings

[openstack-dev] [Ironic] Command structure for OSC plugin

0 votes

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set --provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE'

Question there is does that make sense?

Secondly, maintenance mode makes sense to be part of 'openstack baremetal
set' command, but implementation would be easier and less error-prone
if an antonym for maintenance were used as a flag.

  • openstack baremetal set --maintenance --reason $REASON $NODE
  • openstack baremetal set --maintenance-antonym $NODE

argparse can be used to set them as mutually exclusive and negate
the need to check explicitly for maintenance off and !$REASON

Question is what should the antonym of maintenance be? Since 'active'
is a node state, it was suggest that it be avoided to minimize
confusion.

One thought is to use --disable/--enable, with help text in the
command stating what it does, but it was suggested that display of
the maintenance field would need to change.

Comments? Suggestions?

--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Aug 24, 2015 in openstack-dev by Brad_P._Crochet (1,040 points)  

20 Responses

0 votes

On 24/08/15 11:03 -0400, Brad P. Crochet wrote:
I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

[...snip...]

Secondly, maintenance mode makes sense to be part of 'openstack baremetal
set' command, but implementation would be easier and less error-prone
if an antonym for maintenance were used as a flag.

  • openstack baremetal set --maintenance --reason $REASON $NODE
  • openstack baremetal set --maintenance-antonym $NODE

argparse can be used to set them as mutually exclusive and negate
the need to check explicitly for maintenance off and !$REASON

Question is what should the antonym of maintenance be? Since 'active'
is a node state, it was suggest that it be avoided to minimize
confusion.

One thought is to use --disable/--enable, with help text in the
command stating what it does, but it was suggested that display of
the maintenance field would need to change.

Comments? Suggestions?

Credit to lucasagomes... It makes more sense to use 'openstack
baremetal unset --maintenance' to turn it off. So I think that one can
be put to rest.

--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Brad_P._Crochet (1,040 points)  
0 votes

Hi,

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE'

Question there is does that make sense?

I'm good with both ways.

Secondly, maintenance mode makes sense to be part of 'openstack baremetal
set' command, but implementation would be easier and less error-prone
if an antonym for maintenance were used as a flag.

  • openstack baremetal set --maintenance --reason $REASON $NODE
  • openstack baremetal set --maintenance-antonym $NODE

Maybe:

  • openstack baremetal set --maintenance --reason $REASON $NODE
  • openstack baremetal unset --maintenance $NODE

("unset" instead of "set" for removing a node from maintenance)

Cheers,
Lucas


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Lucas_Alvares_Gomes (6,080 points)   1 2 3
0 votes

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:
I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage] $NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Jay_Pipes (59,760 points)   3 11 15
0 votes

On 08/24/2015 05:41 PM, Jay Pipes wrote:
On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope it
won't also do node updating, will it?)

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Dmitry_Tantsur (18,080 points)   2 5 9
0 votes

On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:
On 08/24/2015 05:41 PM, Jay Pipes wrote:

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope
it won't also do node updating, will it?)

I'm not sure what you mean about node updating... Do you mean setting
properties? Because it does that. Can you be more specific about what
you mean?

Best,
-jay


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

--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Brad_P._Crochet (1,040 points)  
0 votes

On 08/24/2015 07:25 PM, Brad P. Crochet wrote:
On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:

On 08/24/2015 05:41 PM, Jay Pipes wrote:

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope
it won't also do node updating, will it?)

I'm not sure what you mean about node updating... Do you mean setting
properties? Because it does that. Can you be more specific about what
you mean?

So is it a replacement for 3 APIs/commands:
ironic node-set-maintenance
ironic node-set-provision-state
ironic node-update
?

If so, that's too much IMO.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Dmitry_Tantsur (18,080 points)   2 5 9
0 votes

On 24/08/15 19:31 +0200, Dmitry Tantsur wrote:
On 08/24/2015 07:25 PM, Brad P. Crochet wrote:

On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:

On 08/24/2015 05:41 PM, Jay Pipes wrote:

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope
it won't also do node updating, will it?)

I'm not sure what you mean about node updating... Do you mean setting
properties? Because it does that. Can you be more specific about what
you mean?

So is it a replacement for 3 APIs/commands:
ironic node-set-maintenance
ironic node-set-provision-state
ironic node-update
?

If so, that's too much IMO.

Yes, it is. But it does fit with OSC conventions.

Best,
-jay


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

--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Brad_P._Crochet (1,040 points)  
0 votes

From a user perspective, where bare metal and VMs are just different flavors (with varying capabilities), can we not use the same commands (server create/rebuild/...) ? Containers will create the same conceptual problems.

OSC can provide a converged interface but if we just replace '$ ironic XXXX' by '$ openstack baremetal XXXX', this seems to be a missed opportunity to hide the complexity from the end user.

Can we re-use the existing server structures ?

Tim

-----Original Message-----
From: Dmitry Tantsur [mailto:dtantsur@redhat.com]
Sent: 24 August 2015 19:31
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

On 08/24/2015 07:25 PM, Brad P. Crochet wrote:

On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:

On 08/24/2015 05:41 PM, Jay Pipes wrote:

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance
about a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal
[active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical
sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope
it won't also do node updating, will it?)

I'm not sure what you mean about node updating... Do you mean setting
properties? Because it does that. Can you be more specific about what
you mean?

So is it a replacement for 3 APIs/commands:
ironic node-set-maintenance
ironic node-set-provision-state
ironic node-update
?

If so, that's too much IMO.

Best,
-jay




OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Tim_Bell (16,440 points)   1 8 10
0 votes

On 24/08/15 18:19 +0000, Tim Bell wrote:

From a user perspective, where bare metal and VMs are just different flavors (with varying capabilities), can we not use the same commands (server create/rebuild/...) ? Containers will create the same conceptual problems.

OSC can provide a converged interface but if we just replace '$ ironic XXXX' by '$ openstack baremetal XXXX', this seems to be a missed opportunity to hide the complexity from the end user.

Can we re-use the existing server structures ?

Tim

To my knowledge, overriding or enhancing existing commands like that
is not possible.

-----Original Message-----
From: Dmitry Tantsur [mailto:dtantsur@redhat.com]
Sent: 24 August 2015 19:31
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

On 08/24/2015 07:25 PM, Brad P. Crochet wrote:

On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:

On 08/24/2015 05:41 PM, Jay Pipes wrote:

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance
about a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal
[active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical
sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope
it won't also do node updating, will it?)

I'm not sure what you mean about node updating... Do you mean setting
properties? Because it does that. Can you be more specific about what
you mean?

So is it a replacement for 3 APIs/commands:
ironic node-set-maintenance
ironic node-set-provision-state
ironic node-update
?

If so, that's too much IMO.

Best,
-jay




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

--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Brad_P._Crochet (1,040 points)  
0 votes

On 24/08/15 19:31 +0200, Dmitry Tantsur wrote:
On 08/24/2015 07:25 PM, Brad P. Crochet wrote:

On 24/08/15 17:56 +0200, Dmitry Tantsur wrote:

On 08/24/2015 05:41 PM, Jay Pipes wrote:

On 08/24/2015 08:03 AM, Brad P. Crochet wrote:

I am working on extending the current set of patches that implement
the OSC plugin for Ironic. I would like some discussion/guidance about
a couple of command structures.

Currently provisioning state is set via 'openstack baremetal set
--provision-state [active|deleted|rebuild|inspect|provide|manage]
$NODE'

dtantsur suggests it be top-level a command (which I concur)
'openstack baremetal [active|delete|rebuild|inspect|provide|manage]
$NODE'

Question there is does that make sense?

I prefer the current CLI command structure.

openstack baremetal active $NODE does not make grammatical sense.

openstack baremetal activate $NODE would make more sense, but I
actually think the original is easier.

As it is now it's a bit hard to understand what "openstack baremetal
set" command actually does, as it corresponds to 2 API's (and I hope
it won't also do node updating, will it?)

I'm not sure what you mean about node updating... Do you mean setting
properties? Because it does that. Can you be more specific about what
you mean?

So is it a replacement for 3 APIs/commands:
ironic node-set-maintenance
ironic node-set-provision-state
ironic node-update
?

If so, that's too much IMO.

I can see your point there. Perhaps the maintenance and provision
state should be treated more like the power state currently is?

maintenance [--on|--off]
provision state [--active|--deleted|etc.]

Best,
-jay


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

--
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385 (w) 919.301.3231


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2015 by Brad_P._Crochet (1,040 points)  
...