Open Stack

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