Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Brad P. Crochet]

On Mon, Nov 9, 2015 at 7: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.
>

+100.

__
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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Ben Nemec]

On 11/10/2015 05:26 AM, 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.
> 
> 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.

-2.  This is exactly the thing that got us to a place where our GUI was
unusable.  Business logic (and state management around Ironic node
inspection is just that) has to live in the API so all consumers can
take advantage of it.  Otherwise everyone has to reimplement it
themselves and anything but the developer-used CLI interfaces (like
tripleo.sh) fall behind, and we end up right back where we are today.

It's not simply about reducing the number of commands to deploy a 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dean Troyer]

On Tue, Nov 10, 2015 at 9:03 AM, Brad P. Crochet  wrote:

> Actually, the 'baremetal' namespace is exactly what it should be,
> based on other OSC clients. For instance, Neutron uses 'network', Nova
> uses 'server', etc. The idea is that the client should use the service
> type, not the codename of the project that implements it.


I would like to correct this a bit:  'server' and ';network' are resource
names, not namespaces.  The need for namespaces is an unfortunate
consequence of the large number of resources and lack of simple unique
names for them.  We really prefer to do things like use multi-work
resources rather than just blindly paste a prefix onto a command.

For example, there are at least three different users of 'flavor'.
 'compute flavor' was the only thing in the beginning so it naturally got
the bare 'flavor' name.  The other flavor resources ('message flavor' is
the only one I recall ATM) have another word added that acts as a type
specifier, not a blind namespace prefix.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[John Trowbridge]

On 11/10/2015 10:43 AM, Ben Nemec wrote:
> On 11/10/2015 05:26 AM, 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.
>>
>> 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.
> 
> -2.  This is exactly the thing that got us to a place where our GUI was
> unusable.  Business logic (and state management around Ironic node
> inspection is just that) has to live in the API so all consumers can
> take advantage of it.  Otherwise everyone has to reimplement it
> themselves and anything but the 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dean Troyer]

On Tue, Nov 10, 2015 at 7:42 AM, Lennart Regebro 
wrote:

> I'm not so sure about the idea that we can't "hijack" other projects
> namespaces. If only ironic is allowed to use the prefix "baremetal",
> then the prefix should not have been "baremetal" in the first place,
> it should have been "ironic". Which of course means it would just be a
> replacement for the ironic client, making these whole namespaces
> pointless.
>

I would like to paraphrase this a bit and say that the point of namespacing
prefixes is for disambiguation, not to identify which API or project 'owns'
a resource.  Users should not need to know or care about that.  Thus far,
most plugins have simply used their project name (BAD) or SC endpoint type
(still not great) for this.

I would also say that the whole exercise is not pointless even if there
winds up being 'overcloud' and 'undercloud'  top-level commands as the rest
of the exercise in consistency is well worth the effort for our users.

I do agree that many of these should not be in baremetal at all as
> they are not baremetal specific, but tripleo-things, and hence is a
> part of the overcloud/undercloud namespace, and that in the minimum
> teaches us to be more careful with the namespaces. We should probably
> double-check with others first.
>
> Oh, sorry, I mean "We should probably increase cross-team
> communication visibility to synchronize the integrational aspects of
> the openstack client project, going forward."
>

We do keep track of the resources being used by plugins in the OSC docs as
a best-effort central coordination.  This is strictly opt-in as OSC has no
way (yet?) to enforce who 'owns' which resource name.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dmitry Tantsur]

On 11/10/2015 05:18 PM, Ben Nemec wrote:

+1 to moving anything we can into Ironic itself.

I do want to note that if we rename anything, we can't just rip and
replace.  We have users of the current commands, and we need to
deprecate those to give people a chance to move to the new ones.


Definitely. I think I used word deprecation somewhere in this long letter :)



A few more thoughts inline.

On 11/09/2015 06: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.


True, although I feel like an "import from JSON" feature would not be
inappropriate for inclusion in Ironic.  I can't believe that we're the
only ones who would be interested in mass importing nodes from a very
common format like this.


I would warmly welcome such command, but it should not require patching 
os-cloud-config every time we add a new driver or driver property.






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)


I thought that was fixed?  It used to try to introspect nodes that were
in an invalid state (like active), but it shouldn't anymore.


It introspects nodes in "available" state, which is a rude violation of 
the ironic state machine ;)




Unless your objection is that it introspects things in an available
state, which I think has to do with the state Ironic puts (or used to
put) nodes in after registration.  In any case, this one likely requires
some more discussion over how it should work.


Well, if we upgrade baremetal API version we used from 1.6 (essentially 
Kilo) to Liberty one, nodes would appear in a new ENROLL state. I've 
started a patch for it, but I don't have time to finish. Anyone is free 
to overtake: https://review.openstack.org/#/c/235158/





   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.


Well, as I understand it we don't intend for it to be Dell-specific,
it's just that the Dell implementation is the only one that has been
done so far.

That said, since I think this is just layering some TripleO-specific
logic on top of the vendor-specific calls Ironic provides I agree that
it probably doesn't belong in the baremetal namespace.



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.


+1



2. baremetal show capabilities

We'll have this or similar command in ironic, hopefully this cycle.


\o/



3. overcloud nodes introspect --poll --allow-available

  

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Brad P. Crochet]

On Tue, Nov 10, 2015 at 8:42 AM, Lennart Regebro  wrote:
> These changes are fine to me.
>
> I'm not so sure about the idea that we can't "hijack" other projects
> namespaces. If only ironic is allowed to use the prefix "baremetal",
> then the prefix should not have been "baremetal" in the first place,
> it should have been "ironic". Which of course means it would just be a
> replacement for the ironic client, making these whole namespaces
> pointless.

Actually, the 'baremetal' namespace is exactly what it should be,
based on other OSC clients. For instance, Neutron uses 'network', Nova
uses 'server', etc. The idea is that the client should use the service
type, not the codename of the project that implements it.

__
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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Ben Nemec]

+1 to moving anything we can into Ironic itself.

I do want to note that if we rename anything, we can't just rip and
replace.  We have users of the current commands, and we need to
deprecate those to give people a chance to move to the new ones.

A few more thoughts inline.

On 11/09/2015 06: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.

True, although I feel like an "import from JSON" feature would not be
inappropriate for inclusion in Ironic.  I can't believe that we're the
only ones who would be interested in mass importing nodes from a very
common format like this.

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

I thought that was fixed?  It used to try to introspect nodes that were
in an invalid state (like active), but it shouldn't anymore.

Unless your objection is that it introspects things in an available
state, which I think has to do with the state Ironic puts (or used to
put) nodes in after registration.  In any case, this one likely requires
some more discussion over how it should work.

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

Well, as I understand it we don't intend for it to be Dell-specific,
it's just that the Dell implementation is the only one that has been
done so far.

That said, since I think this is just layering some TripleO-specific
logic on top of the vendor-specific calls Ironic provides I agree that
it probably doesn't belong in the baremetal namespace.

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

+1

> 
> 2. baremetal show capabilities
> 
>We'll have this or similar command in ironic, hopefully this cycle.

\o/

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

The only thing is that because this does the state manipulation, polling
is essentially the only way it can work, although moving this to the API
will change that.  Like I said above, I think this one is going to
require some ongoing discussion as part of the API work.

> 
> 4. overcloud nodes import --dry-run
> 
>

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Ben Nemec]

On 11/10/2015 11:18 AM, Dmitry Tantsur wrote:
> On 11/10/2015 06:08 PM, Ben Nemec wrote:
>> On 11/10/2015 10:28 AM, John Trowbridge wrote:
>>>
>>>
>>> On 11/10/2015 10:43 AM, Ben Nemec wrote:
 On 11/10/2015 05:26 AM, 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.
>
> 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
> 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Ben Nemec]

On 11/10/2015 10:28 AM, John Trowbridge wrote:
> 
> 
> On 11/10/2015 10:43 AM, Ben Nemec wrote:
>> On 11/10/2015 05:26 AM, 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.
>>>
>>> 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.
>>
>> -2.  This is exactly the thing that got us to a place where our GUI was
>> unusable.  Business logic (and state management around Ironic node
>> 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dmitry Tantsur]

On 11/10/2015 06:08 PM, Ben Nemec wrote:

On 11/10/2015 10:28 AM, John Trowbridge wrote:



On 11/10/2015 10:43 AM, Ben Nemec wrote:

On 11/10/2015 05:26 AM, 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.

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.


-2.  This is exactly the thing that got us to a place where our GUI was
unusable.  Business logic (and state management around Ironic node
inspection is just that) has to live in the API so all consumers can
take advantage of it.  Otherwise everyone has to reimplement it
themselves and anything but the developer-used CLI interfaces (like
tripleo.sh) fall behind, and we end up right back where we are today.

It's not simply about reducing the number of commands to deploy a cloud,
it's also (and more importantly) about codifying the process behind an
API that can be used by the CLI, GUI, and any other future 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Zane Bitter]

On 09/11/15 07:44, Dmitry Tantsur wrote:


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


Terminology around these machines is always confusing, because they are 
related to both the undercloud (in the sense of being resources managed 
the undercloud's Ironic) and the overcloud (in the sense of being the 
substrate on which the overcloud is deployed).


I have probably been using the terminology wrongly, but FWIW it was 
extremely surprising to me to see these fall into the overcloud bucket, 
given that at the time they're used the overcloud doesn't even exist. (I 
guess I would have gone with "undercloud baremetal", although I can see 
how that could potentially be equally confusing.)


cheers,
Zane.

__
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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Ben Nemec]

On 11/10/2015 10:40 AM, Dmitry Tantsur wrote:
> On 11/10/2015 05:18 PM, Ben Nemec wrote:
>> +1 to moving anything we can into Ironic itself.
>>
>> I do want to note that if we rename anything, we can't just rip and
>> replace.  We have users of the current commands, and we need to
>> deprecate those to give people a chance to move to the new ones.
> 
> Definitely. I think I used word deprecation somewhere in this long letter :)

Cool, just wanted to make sure we were all on the same page. :-)

> 
>>
>> A few more thoughts inline.
>>
>> On 11/09/2015 06: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.
>>
>> True, although I feel like an "import from JSON" feature would not be
>> inappropriate for inclusion in Ironic.  I can't believe that we're the
>> only ones who would be interested in mass importing nodes from a very
>> common format like this.
> 
> I would warmly welcome such command, but it should not require patching 
> os-cloud-config every time we add a new driver or driver property.

Yeah, I wonder if we should just drop the os-cloud-config abstraction
and have the JSON contain the actual node parameters.  A bunch of the
drivers have driver-specific configuration options anyway, so it's not
like you can just change the driver name without altering the other bits
of the configuration anyway.

The only drawback to that is if a driver changed the name of a
parameter, but if this lived in Ironic you could just add a name mapping
to the import code at the same time, whereas having it in
os-cloud-config you'd still break, but there's an extra layer of
indirection to getting it fixed.

The more I think about it the more I like it.  Not sure I'm going to
have time to follow up though. :-/

> 
>>
>>>
>>> 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)
>>
>> I thought that was fixed?  It used to try to introspect nodes that were
>> in an invalid state (like active), but it shouldn't anymore.
> 
> It introspects nodes in "available" state, which is a rude violation of 
> the ironic state machine ;)
> 
>>
>> Unless your objection is that it introspects things in an available
>> state, which I think has to do with the state Ironic puts (or used to
>> put) nodes in after registration.  In any case, this one likely requires
>> some more discussion over how it should work.
> 
> Well, if we upgrade baremetal API version we used from 1.6 (essentially 
> Kilo) to Liberty one, nodes would appear in a new ENROLL state. I've 
> started a patch for it, but I don't have time to finish. Anyone is free 
> to overtake: https://review.openstack.org/#/c/235158/

This seems like the right thing to do all around.  It allows us to
introspect newly registered nodes without breaking the Ironic state
machine.  I've subscribed to the review at least, will see if I have
time to do anything with it.

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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[John Trowbridge]

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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dmitry Tantsur]

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: 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dmitry Tantsur]

On 11/10/2015 02:42 PM, Lennart Regebro wrote:

These changes are fine to me.

I'm not so sure about the idea that we can't "hijack" other projects
namespaces. If only ironic is allowed to use the prefix "baremetal",
then the prefix should not have been "baremetal" in the first place,
it should have been "ironic". Which of course means it would just be a
replacement for the ironic client, making these whole namespaces
pointless.


That's not true, ironic is officially called the Bare metal service, so 
"baremetal" is its official short name.


That said, I'm not saying we can never use other's namespaces. I only 
state that this should be done in coordination with projects and with 
care to make the new commands generic enough.




I do agree that many of these should not be in baremetal at all as
they are not baremetal specific, but tripleo-things, and hence is a
part of the overcloud/undercloud namespace, and that in the minimum
teaches us to be more careful with the namespaces. We should probably
double-check with others first.

Oh, sorry, I mean "We should probably increase cross-team
communication visibility to synchronize the integrational aspects of
the openstack client project, going forward."


:)




On Mon, Nov 9, 2015 at 1:44 PM, 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

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.

4. overcloud nodes import --dry-run

   could be a replacement for "baremetal instackenv validate".


Please let me know what you think.

Cheers,
Dmitry.


__
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 

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Miles Gould]

- Original Message -
> From: "Lennart Regebro" <lrege...@redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Sent: Tuesday, 10 November, 2015 1:42:52 PM
> Subject: Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other 
> projects' OSC namespaces
> 
> These changes are fine to me.
> 
> I'm not so sure about the idea that we can't "hijack" other projects
> namespaces. If only ironic is allowed to use the prefix "baremetal",
> then the prefix should not have been "baremetal" in the first place,
> it should have been "ironic". Which of course means it would just be a
> replacement for the ironic client, making these whole namespaces
> pointless.

I thought the point of the new namespaces was to reduce cognitive load on users 
- "what's the command for doing things with baremetal nodes, again? Some pun on 
metals and 90s pop music - metallica? goldie? lithium? ironmaiden?"

Miles

__
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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Lennart Regebro]

These changes are fine to me.

I'm not so sure about the idea that we can't "hijack" other projects
namespaces. If only ironic is allowed to use the prefix "baremetal",
then the prefix should not have been "baremetal" in the first place,
it should have been "ironic". Which of course means it would just be a
replacement for the ironic client, making these whole namespaces
pointless.

I do agree that many of these should not be in baremetal at all as
they are not baremetal specific, but tripleo-things, and hence is a
part of the overcloud/undercloud namespace, and that in the minimum
teaches us to be more careful with the namespaces. We should probably
double-check with others first.

Oh, sorry, I mean "We should probably increase cross-team
communication visibility to synchronize the integrational aspects of
the openstack client project, going forward."


On Mon, Nov 9, 2015 at 1:44 PM, 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
>
> 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.
>
> 4. overcloud nodes import --dry-run
>
>   could be a replacement for "baremetal instackenv validate".
>
>
> Please let me know what you think.
>
> Cheers,
> Dmitry.
>
>
> __
> 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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dougal Matthews]

On 9 November 2015 at 12:44, 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).
>

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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Dmitry Tantsur]

On 11/09/2015 03:04 PM, Dougal Matthews wrote:

On 9 November 2015 at 12:44, 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).


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