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