On 11/09/2015 03:04 PM, Dougal Matthews wrote:
On 9 November 2015 at 12:44, Dmitry Tantsur <[email protected]
<mailto:[email protected]>> wrote:
Hi OOO'ers, hopefully the subject caught your attentions :)
Currently, tripleoclient exposes several commands in "openstack
baremetal" and "openstack baremetal introspection" namespaces
belonging to ironic and ironic-inspector accordingly. TL;DR of this
email is to deprecate them and move to TripleO-specific namespaces.
Read on to know why.
Problem
=======
I realized that we're doing a wrong thing when people started asking
me why "baremetal introspection start" and "baremetal introspection
bulk start" behave so differently (the former is from
ironic-inspector, the latter is from tripleoclient). The problem
with TripleO commands is that they're highly opinionated workflows
commands, but there's no way a user can distinguish them from
general-purpose ironic/ironic-inspector commands. The way some of
them work is not generic enough ("baremetal import"), or uses
different defaults from an upstream project ("configure boot"), or
does something completely unacceptable upstream (e.g. the way
"introspection bulk start" deals with node states).
A big +1 to the idea.
We originally done this because we wanted to make it feel more
"integrated", but it never quite worked. I completely agree with all the
justifications below.
So, here are commands that tripleoclient exposes with my comments:
1. baremetal instackenv validate
This command assumes there's an "baremetal instackenv" object,
while instackenv is a tripleo-specific file format.
2. baremetal import
This command supports a limited subset of ironic drivers and
driver properties, only those known to os-cloud-config.
3. baremetal introspection bulk start
This command does several bad (IMO) things:
a. Messes with ironic node states
b. Operates implicitly on all nodes (in a wrong state)
c. Defaults to polling
4. baremetal show capabilities
This is the only commands that is generic enough and could
actually make it to ironicclient itself.
5. baremetal introspection bulk status
See "bulk start" above.
6. baremetal configure ready state
First of all, this and the next command use "baremetal configure"
prefix. I would not promise we'll never start using it in ironic,
breaking the whole TripleO.
Seconds, it's actually DELL-specific.
heh, that I didn't know!
7. baremetal configure boot
This one is nearly ok, but it defaults to local boot, which is not
an upstream default. Default values for images may not work outside
of TripleO as well.
Proposal
========
As we already have "openstack undercloud" and "openstack overcloud"
prefixes for TripleO, I suggest we move these commands under
"openstack overcloud nodes" namespace. So we end up with:
overcloud nodes import
overcloud nodes configure ready state --drac
overcloud nodes configure boot
I think this is probably okay, but I wonder if "nodes" is a bit generic?
Why not "overcloud baremetal" for consistency?
I don't have a strong opinion on it :)
As you see, I require an explicit --drac argument for "ready state"
command. As to the remaining commands:
1. baremetal introspection status --all
This is fine to move to inspector-client, as inspector knows
which nodes are/were on introspection. We'll need a new API though.
A new API endpoint in Ironic Inspector?
Yeah, a new endpoint to report all nodes that are/were on inspection.
2. baremetal show capabilities
We'll have this or similar command in ironic, hopefully this cycle.
3. overcloud nodes introspect --poll --allow-available
I believe that we need to make 2 things explicit in this
replacement for "introspection bulk status": polling and operating
on "available" nodes.
4. overcloud nodes import --dry-run
could be a replacement for "baremetal instackenv validate".
Please let me know what you think.
Thanks for bringing this up, it should make everything much clearer for
everyone.
Great! I've also added this topic to the tomorrow's meeting to increase
visibility.
Cheers,
Dmitry.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
