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

Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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.

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.

Doug

-----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


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 Doug_Hellmann (87,520 points)   4 6 14
0 votes

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann doug@doughellmann.com
wrote:

Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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 ?

I've wondered about how users would see doing this, we've done it already
with the quota and limits commands (blurring the distinction between
project APIs). At some level I am sure users really do not care about some
of our project distinctions.

To my knowledge, overriding or enhancing existing commands like that

is not possible.

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.

I do have an experimental plugin that hooks the server create command to
add some options and change its behaviour so it is possible, but right now
I wouldn't call it supported at all. That might be something that we could
consider doing though for things like this.

The current model for commands calling multiple project APIs is to put them
in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations into
the current verbs as much as possible. It is best to think in terms of how
the CLI user is thinking and what she wants to do, and not how the REST or
Python API is written. In this case, 'baremetal' is a type of server, a
set of attributes of a server, etc. As mentioned earlier, containers will
also have a similar paradigm to consider.

dt

--

Dean Troyer
dtroyer@gmail.com


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 Sep 1, 2015 by Dean_Troyer (13,100 points)   1 3 4
0 votes

That would be great to have plugins on the commands which are relevant to multiple projects… avoiding exposing all of the underlying projects as prefixes and getting more consistency would be very appreciated by the users.

Tim

From: Dean Troyer [mailto:dtroyer@gmail.com]
Sent: 01 September 2015 22:47
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann doug@doughellmann.com wrote:
Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
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 ?

I've wondered about how users would see doing this, we've done it already with the quota and limits commands (blurring the distinction between project APIs). At some level I am sure users really do not care about some of our project distinctions.

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

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.

I do have an experimental plugin that hooks the server create command to add some options and change its behaviour so it is possible, but right now I wouldn't call it supported at all. That might be something that we could consider doing though for things like this.

The current model for commands calling multiple project APIs is to put them in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations into the current verbs as much as possible. It is best to think in terms of how the CLI user is thinking and what she wants to do, and not how the REST or Python API is written. In this case, 'baremetal' is a type of server, a set of attributes of a server, etc. As mentioned earlier, containers will also have a similar paradigm to consider.

dt

--

Dean Troyer
dtroyer@gmail.com


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 Sep 2, 2015 by Tim_Bell (16,440 points)   1 8 11
0 votes

Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +0000:

That would be great to have plugins on the commands which are relevant to multiple projects… avoiding exposing all of the underlying projects as prefixes and getting more consistency would be very appreciated by the users.

That works in some cases, but in a lot of cases things that are
superficially similar have important differences in the inputs they
take. In those cases, it's better to be explicit about the differences
than to force the concepts together in a way that makes OSC present only
the least-common denominator interface.

Doug

Tim

From: Dean Troyer [mailto:dtroyer@gmail.com]
Sent: 01 September 2015 22:47
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann doug@doughellmann.com wrote:
Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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 ?

I've wondered about how users would see doing this, we've done it already with the quota and limits commands (blurring the distinction between project APIs). At some level I am sure users really do not care about some of our project distinctions.

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

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.

I do have an experimental plugin that hooks the server create command to add some options and change its behaviour so it is possible, but right now I wouldn't call it supported at all. That might be something that we could consider doing though for things like this.

The current model for commands calling multiple project APIs is to put them in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations into the current verbs as much as possible. It is best to think in terms of how the CLI user is thinking and what she wants to do, and not how the REST or Python API is written. In this case, 'baremetal' is a type of server, a set of attributes of a server, etc. As mentioned earlier, containers will also have a similar paradigm to consider.

dt


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 Sep 2, 2015 by Doug_Hellmann (87,520 points)   4 6 14
0 votes

-----Original Message-----
From: Doug Hellmann [mailto:doug@doughellmann.com]
Sent: 02 September 2015 16:21
To: openstack-dev openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +0000:

That would be great to have plugins on the commands which are relevant
to multiple projects… avoiding exposing all of the underlying projects as
prefixes and getting more consistency would be very appreciated by the
users.

That works in some cases, but in a lot of cases things that are superficially
similar have important differences in the inputs they take. In those cases, it's
better to be explicit about the differences than to force the concepts together
in a way that makes OSC present only the least-common denominator
interface.

I think the difference are in the options rather than the prefixes. Thus, if I want to create a bare metal server, I should be able to use 'openstack create' rather than 'openstack ironic create'. The various implications on options etc. are clearly dependent on the target environment.

I would simply like to avoid that the OSC becomes a prefix, i.e. you need to know that ironic is for baremetal. If options are presented which are not supported in the desired context, they should be rejected.

At CERN, we're using OSC as the default CLI. This is partly because the support for Keystone v3 API is much more advanced but also because we do not want our end users to know the list of OpenStack projects, only the services we are offering them.

Tim

Doug

Tim

From: Dean Troyer [mailto:dtroyer@gmail.com]
Sent: 01 September 2015 22:47
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann
doug@doughellmann.com wrote:
Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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 ?

I've wondered about how users would see doing this, we've done it already
with the quota and limits commands (blurring the distinction between
project APIs). At some level I am sure users really do not care about some of
our project distinctions.

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

You would have to do it in tree, by making the existing commands smart
enough to talk to both nova and ironic, first to find the server
(which service knows about something with UUID XYZ?) and then to take
the appropriate action on that server using the right client. So it
could be done, but it might lose some of the nuance between the server
types by munging them into the same command. I don't know what sorts
of operations are different, but it would be worth doing the analysis
to see.

I do have an experimental plugin that hooks the server create command to
add some options and change its behaviour so it is possible, but right now I
wouldn't call it supported at all. That might be something that we could
consider doing though for things like this.

The current model for commands calling multiple project APIs is to put
them in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations
into the current verbs as much as possible. It is best to think in terms of how
the CLI user is thinking and what she wants to do, and not how the REST or
Python API is written. In this case, 'baremetal' is a type of server, a set of
attributes of a server, etc. As mentioned earlier, containers will also have a
similar paradigm to consider.

dt



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 Sep 2, 2015 by Tim_Bell (16,440 points)   1 8 11
0 votes

Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +0000:

-----Original Message-----
From: Doug Hellmann [mailto:doug@doughellmann.com]
Sent: 02 September 2015 16:21
To: openstack-dev openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +0000:

That would be great to have plugins on the commands which are relevant
to multiple projects… avoiding exposing all of the underlying projects as
prefixes and getting more consistency would be very appreciated by the
users.

That works in some cases, but in a lot of cases things that are superficially
similar have important differences in the inputs they take. In those cases, it's
better to be explicit about the differences than to force the concepts together
in a way that makes OSC present only the least-common denominator
interface.

I think the difference are in the options rather than the prefixes. Thus, if I want to create a bare metal server, I should be able to use 'openstack create' rather than 'openstack ironic create'. The various implications on options etc. are clearly dependent on the target environment.

I would simply like to avoid that the OSC becomes a prefix, i.e. you need to know that ironic is for baremetal. If options are presented which are not supported in the desired context, they should be rejected.

This is the long-standing debate over whether it's better to constrain
the inputs up front, or accept anything and then validate it and
reject bad inputs after they are presented. My UI training always
indicated that assisting to get the inputs right up front was better,
and that's what I think we're trying to do with OSC.

Having an "openstack server create" command that works for all
services that produce things that look like servers means the user
has to somehow determine which of the options are related to which
of the types of servers. We can do some work to group options in
help output, and express which are mutually exclusive, but that
only goes so far. At some point the user ends up having to know
that when "--type baremetal" is provided, the "--container-type"
option used for containers isn't valid at all. There's no way to
express that level of detail in the tools we're using right now,
in part because it results in a more complex UI.

Having an "openstack baremetal create" command is more like the
up-front constraint, because the user can use --help to discover
exactly which options are valid for a baremetal server. It shifts
that "--type baremetal" option into the command name, where the
tools we use to build OSC can let us express exactly which other
options are valid, and (implicitly) which are not.

Placing "baremetal" as the first part of the command was an intentional
choice -- we call this the "noun first" form, versus the "verb
first" form "create baremetal". We considered that the user understands
what kind of resource they're trying to issue a command on, but may
not know all of the commands available for that resource type. With
tab-completion enabled, "openstack baremetal" will give them
the list of commands for doing anything to baremetal servers. It
also means all of the commands for a given resource type are listed
together in the global help output where we list all available
subcommands.

At CERN, we're using OSC as the default CLI. This is partly because the support for Keystone v3 API is much more advanced but also because we do not want our end users to know the list of OpenStack projects, only the services we are offering them.

Using resource type names rather than services is definitely
preferred. That falls down when we have 2 services providing similar
(or the same) resource types. For example, I could see some overlap
in command names and resource types for Cue and Zaqar.

Doug

Tim

Doug

Tim

From: Dean Troyer [mailto:dtroyer@gmail.com]
Sent: 01 September 2015 22:47
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ironic] Command structure for OSC plugin

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann
doug@doughellmann.com wrote:
Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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 ?

I've wondered about how users would see doing this, we've done it already
with the quota and limits commands (blurring the distinction between
project APIs). At some level I am sure users really do not care about some of
our project distinctions.

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

You would have to do it in tree, by making the existing commands smart
enough to talk to both nova and ironic, first to find the server
(which service knows about something with UUID XYZ?) and then to take
the appropriate action on that server using the right client. So it
could be done, but it might lose some of the nuance between the server
types by munging them into the same command. I don't know what sorts
of operations are different, but it would be worth doing the analysis
to see.

I do have an experimental plugin that hooks the server create command to
add some options and change its behaviour so it is possible, but right now I
wouldn't call it supported at all. That might be something that we could
consider doing though for things like this.

The current model for commands calling multiple project APIs is to put
them in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations
into the current verbs as much as possible. It is best to think in terms of how
the CLI user is thinking and what she wants to do, and not how the REST or
Python API is written. In this case, 'baremetal' is a type of server, a set of
attributes of a server, etc. As mentioned earlier, containers will also have a
similar paradigm to consider.

dt



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 Sep 2, 2015 by Doug_Hellmann (87,520 points)   4 6 14
0 votes

On Wed, Sep 2, 2015 at 2:29 PM, Doug Hellmann doug@doughellmann.com wrote:

Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +0000:

I think the difference are in the options rather than the prefixes.
Thus, if I want to create a bare metal server, I should be able to use
'openstack create' rather than 'openstack ironic create'. The various
implications on options etc. are clearly dependent on the target
environment.

I would simply like to avoid that the OSC becomes a prefix, i.e. you
need to know that ironic is for baremetal. If options are presented which
are not supported in the desired context, they should be rejected.

This is the long-standing debate over whether it's better to constrain
the inputs up front, or accept anything and then validate it and
reject bad inputs after they are presented. My UI training always
indicated that assisting to get the inputs right up front was better,
and that's what I think we're trying to do with OSC.

Having an "openstack server create" command that works for all
services that produce things that look like servers means the user
has to somehow determine which of the options are related to which
of the types of servers. We can do some work to group options in
help output, and express which are mutually exclusive, but that
only goes so far. At some point the user ends up having to know
that when "--type baremetal" is provided, the "--container-type"
option used for containers isn't valid at all. There's no way to
express that level of detail in the tools we're using right now,
in part because it results in a more complex UI.

To do this now requires manually implementing it in the commands
themselves, but I am willing to do that as I do think the end result is a
lower footprint UI. The biggest problem we have is the help output, that
is not solved yet, but we have been clear in the documentation when options
are only applicable with or without other options also present.

Having an "openstack baremetal create" command is more like the
up-front constraint, because the user can use --help to discover
exactly which options are valid for a baremetal server. It shifts
that "--type baremetal" option into the command name, where the
tools we use to build OSC can let us express exactly which other
options are valid, and (implicitly) which are not.

We have started using multiple word nouns for disambiguation, in this case,
I would suggest 'baremetal server' as 'baremetal' is not a thing by
itself. I think this is an acceptable compromise as it still contains
'server' as the concepts involved are fundamentally the same thing.
'server create --type baremental' would still be my preference, even with
it being more work inside OSC/plugins.

dt

--

Dean Troyer
dtroyer@gmail.com


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 Sep 2, 2015 by Dean_Troyer (13,100 points)   1 3 4
0 votes

On Tue, Sep 01, 2015 at 03:47:03PM -0500, Dean Troyer wrote:
[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann doug@doughellmann.com
wrote:

Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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 ?

I've wondered about how users would see doing this, we've done it already
with the quota and limits commands (blurring the distinction between
project APIs). At some level I am sure users really do not care about some
of our project distinctions.

To my knowledge, overriding or enhancing existing commands like that

is not possible.

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.

I do have an experimental plugin that hooks the server create command to
add some options and change its behaviour so it is possible, but right now
I wouldn't call it supported at all. That might be something that we could
consider doing though for things like this.

The current model for commands calling multiple project APIs is to put them
in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations into
the current verbs as much as possible. It is best to think in terms of how
the CLI user is thinking and what she wants to do, and not how the REST or
Python API is written. In this case, 'baremetal' is a type of server, a
set of attributes of a server, etc. As mentioned earlier, containers will
also have a similar paradigm to consider.

Disclaimer: I don't know much about OSC or its syntax, command
structure, etc. These may not be well-formed thoughts. :)

While it would be really cool to support the same command to do things
to nova servers or do things to ironic servers, I don't know that it's
reasonable to do so.

Ironic is an admin-only API, that supports running standalone or behind
a Nova installation with the Nova virt driver. The API is primarily used
by Nova, or by admins for management. In the case of a standalone
configuration, an admin can use the Ironic API to deploy a server,
though the recommended approach is to use Bifrost[0] to simplify that.
In the case of Ironic behind Nova, users are expected to boot baremetal
servers through Nova, as indicated by a flavor.

So, many of the nova commands (openstack server foo) don't make sense in
an Ironic context, and vice versa. It would also be difficult to
determine if the commands should go through Nova or through Ironic.
The path could be something like: check that Ironic exists, see if user
has access, hence standalone mode (oh wait, operators probably have
access to manage Ironic and deploy baremetal through Nova, what do?).

I think we should think of "openstack baremetal foo" as commands to
manage the baremetal service (Ironic), as that is what the API is
primarily intended for. Then "openstack server foo" just does what it
does today, and if the flavor happens to be a baremetal flavor, the user
gets a baremetal server.

// jim

[0] https://github.com/openstack/bifrost


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 Sep 9, 2015 by Jim_Rollenhagen (12,800 points)   2 3 3
0 votes

On 09/09/2015 06:48 PM, Jim Rollenhagen wrote:
On Tue, Sep 01, 2015 at 03:47:03PM -0500, Dean Troyer wrote:

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann doug@doughellmann.com
wrote:

Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:

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 ?

I've wondered about how users would see doing this, we've done it already
with the quota and limits commands (blurring the distinction between
project APIs). At some level I am sure users really do not care about some
of our project distinctions.

To my knowledge, overriding or enhancing existing commands like that

is not possible.

You would have to do it in tree, by making the existing commands
smart enough to talk to both nova and ironic, first to find the
server (which service knows about something with UUID XYZ?) and
then to take the appropriate action on that server using the right
client. So it could be done, but it might lose some of the nuance
between the server types by munging them into the same command. I
don't know what sorts of operations are different, but it would be
worth doing the analysis to see.

I do have an experimental plugin that hooks the server create command to
add some options and change its behaviour so it is possible, but right now
I wouldn't call it supported at all. That might be something that we could
consider doing though for things like this.

The current model for commands calling multiple project APIs is to put them
in openstackclient.common, so yes, in-tree.

Overall, though, to stay consistent with OSC you would map operations into
the current verbs as much as possible. It is best to think in terms of how
the CLI user is thinking and what she wants to do, and not how the REST or
Python API is written. In this case, 'baremetal' is a type of server, a
set of attributes of a server, etc. As mentioned earlier, containers will
also have a similar paradigm to consider.

Disclaimer: I don't know much about OSC or its syntax, command
structure, etc. These may not be well-formed thoughts. :)

With the same disclaimer applied...

While it would be really cool to support the same command to do things
to nova servers or do things to ironic servers, I don't know that it's
reasonable to do so.

Ironic is an admin-only API, that supports running standalone or behind
a Nova installation with the Nova virt driver. The API is primarily used
by Nova, or by admins for management. In the case of a standalone
configuration, an admin can use the Ironic API to deploy a server,
though the recommended approach is to use Bifrost[0] to simplify that.
In the case of Ironic behind Nova, users are expected to boot baremetal
servers through Nova, as indicated by a flavor.

So, many of the nova commands (openstack server foo) don't make sense in
an Ironic context, and vice versa. It would also be difficult to
determine if the commands should go through Nova or through Ironic.
The path could be something like: check that Ironic exists, see if user
has access, hence standalone mode (oh wait, operators probably have
access to manage Ironic and deploy baremetal through Nova, what do?).

I second this. I'd like also to add that in case of Ironic "server
create" may involve actually several complex actions, that do not map to
'nova boot'. First of all we create a node record in database, second we
check it's power credentials, third we do properties inspection, finally
we do cleaning. None of these make any sense on a virtual environment.

I think we should think of "openstack baremetal foo" as commands to
manage the baremetal service (Ironic), as that is what the API is
primarily intended for. Then "openstack server foo" just does what it
does today, and if the flavor happens to be a baremetal flavor, the user
gets a baremetal server.

// jim

[0] https://github.com/openstack/bifrost


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 Sep 10, 2015 by Dmitry_Tantsur (18,080 points)   2 5 10
0 votes

Hi,

Disclaimer: I don't know much about OSC or its syntax, command
structure, etc. These may not be well-formed thoughts. :)

Same here, I don't know much about OSC in general.

So, many of the nova commands (openstack server foo) don't make sense in
an Ironic context, and vice versa. It would also be difficult to
determine if the commands should go through Nova or through Ironic.
The path could be something like: check that Ironic exists, see if user
has access, hence standalone mode (oh wait, operators probably have
access to manage Ironic and deploy baremetal through Nova, what do?).

I was looking at the list of OSC commands [1], some I can think it
could be possible to map to Ironic functions are:

  • openstack server create
  • openstack server delete
  • openstack server list
  • openstack server show
  • openstack server reboot
  • openstack server rebuild

But when I go to the specifics, I find it hard to map all the
parameters supported for it in the Ironic context, i.e the "openstack
server list" command [2] supports parameters such as "--flavor" or
"--instance-name" to search by flavor or instance name wouldn't be
possible to be implement in Ironic at present (we don't keep such
information registered within the deployed Nodes); among other things
"--ip", "--ip6", etc...

So I think it may worth to do a better research about those commands
and it's parameters to see what can be reused in the Ironic context.
But, at first glance it also seems to me that this is going to bring
more confusion around the usage of the CLI than actually help by
having generic commands for different services.

[1] http://docs.openstack.org/cli-reference/content/openstackclient_commands.html
[2] http://docs.openstack.org/cli-reference/content/openstackclient_commands.html#openstackclient_subcommand_server_list

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 Sep 10, 2015 by Lucas_Alvares_Gomes (6,080 points)   1 2 3
...