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

[Dmitry Tantsur]

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


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

On 24/08/15 18:19 +, 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

' by '$ openstack baremetal ', 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-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] Command structure for OSC plugin

[Lucas Alvares Gomes]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jim Rollenhagen]

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 
> wrote:
> 
> > Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > > On 24/08/15 18:19 +, 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
> > ' by '$ openstack baremetal ', 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tim Bell]

> -Original Message-
> From: Doug Hellmann [mailto:d...@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 +:
> > 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:dtro...@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
> <d...@doughellmann.com<mailto:d...@doughellmann.com>> wrote:
> > Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > > On 24/08/15 18:19 +, 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
> ' by '$ openstack baremetal ', 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
> >
> 
> ___

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

[Doug Hellmann]

Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +:
> > -Original Message-
> > From: Doug Hellmann [mailto:d...@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 +:
> > > 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:dtro...@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
> > <d...@doughellmann.com<mailto:d...@doughellmann.com>> wrote:
> > > Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> &

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

[Dean Troyer]

On Wed, Sep 2, 2015 at 2:29 PM, Doug Hellmann  wrote:

> Excerpts from Tim Bell's message of 2015-09-02 18:50:57 +:
> > 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
dtro...@gmail.com
__
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] Command structure for OSC plugin

[Doug Hellmann]

Excerpts from Tim Bell's message of 2015-09-02 05:15:35 +:
> 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:dtro...@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 
> <d...@doughellmann.com<mailto:d...@doughellmann.com>> wrote:
> Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > On 24/08/15 18:19 +, 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 
> > >' by '$ openstack baremetal ', 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dean Troyer]

[late catch-up]

On Mon, Aug 24, 2015 at 2:56 PM, Doug Hellmann 
wrote:

> Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> > On 24/08/15 18:19 +, 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
> ' by '$ openstack baremetal ', 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
dtro...@gmail.com
__
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] Command structure for OSC plugin

[Tim Bell]

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:dtro...@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 
<d...@doughellmann.com<mailto:d...@doughellmann.com>> wrote:
Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
> On 24/08/15 18:19 +, 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 ' 
> >by '$ openstack baremetal ', 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
dtro...@gmail.com<mailto:dtro...@gmail.com>
__
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] Command structure for OSC plugin

[Brad P. Crochet]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Lucas Alvares Gomes]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dmitry Tantsur]

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-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] Command structure for OSC plugin

[Jay Pipes]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brad P. Crochet]

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


--
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dmitry Tantsur]

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-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 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] Command structure for OSC plugin

[Brad P. Crochet]

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


--
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tim Bell]

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 ' by 
'$ openstack baremetal ', 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:dtant...@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-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 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] Command structure for OSC plugin

[Brad P. Crochet]

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


--
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brad P. Crochet]

On 24/08/15 18:19 +, 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 ' by 
'$ openstack baremetal ', 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:dtant...@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-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 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


--
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

Excerpts from Brad P. Crochet's message of 2015-08-24 15:35:59 -0400:
 On 24/08/15 18:19 +, 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 ' 
 by '$ openstack baremetal ', 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:dtant...@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-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 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 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