On 11/10/2015 12:26 PM, John Trowbridge wrote:
On 11/09/2015 07:44 AM, Dmitry Tantsur 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).
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
I have considered this whole command as a bug for a while now. I
understand what we were trying to do and why, but it is pretty bad to
hijack another project's namespace with a command that would get a firm
-2 there.
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.
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
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.
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.
I am not totally convinced that we gain a huge amount by hiding the
state manipulation in this command. We need to move that logic to
tripleo-common anyways, so I think it is worth considering splitting it
from the introspect command.
+1
Dmitry and I discussed briefly at summit having the ability to pass a
list of nodes to the inspector client for introspection as well. So if
we separated out the bulk state manipulation bit, we could just use that.
And here it goes: https://review.openstack.org/#/c/243541/ :)
The only missing bit would be polling, it's bug
https://bugs.launchpad.net/python-ironic-inspector-client/+bug/1480649
if someone feels like working on it.
I get that this is going in the opposite direction of the original
intention of lowering the amount of commands needed to get a functional
deployment. However, I think that goal is better solved elsewhere
(tripleo.sh, some ansible playbooks, etc.). Instead it would be nice if
the tripleoclient was more transparent.
+100
Thanks Dmitry for starting this discussion.
__________________________________________________________________________
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
