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