Open Stack

On 9 November 2015 at 12:44, Dmitry Tantsur <dtantsur at redhat.com> 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?



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


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.



>
> Cheers,
> Dmitry.
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/47afa9ad/attachment.html>