Open Stack

On Wed, Aug 26, 2015 at 11:09 PM, Julia Kreger
<juliaashleykreger at gmail.com> wrote:
> My apologies for not expressing my thoughts on this matter
> sooner, however I've had to spend some time collecting my
> thoughts.
>
> To me, it seems like we do not trust our users.  Granted,
> when I say users, I mean administrators who likely know more
> about the disposition and capabilities of their fleet than
> could ever be discovered or inferred via software.
>
> Sure, we have other users, mainly in the form of consumers,
> asking Ironic for hardware to be deployed, but the driver for
> adoption is who feels the least amount of pain.
>
> API versioning aside, I have to ask the community, what is
> more important?
>
> - An inflexible workflow that forces an administrator to
> always have a green field, and to step through a workflow
> that we've dictated, which may not apply to their operational
> scenario, ultimately driving them to write custom code to
> inject "new" nodes into the database directly, which will
> surely break from time to time, causing them to hate Ironic
> and look for a different solution.
>
> - A happy administrator that has the capabilities to do their
> job (and thus manage the baremetal node wherever it is in the
> operator's lifecycle) in an efficient fashion, thus causing
> them to fall in love with Ironic.
>

I'm sorry, I find the language used in this reply very offensive.
That's not even a real question, due the alternatives you're basically
asking the community "What's more important, be happy or be sad ? Be
efficient or not efficient?"

It's not about an "inflexible workflow" which "dictates" what people
do making them "hate" the project. It's about finding a common pattern
for an work flow that will work for all types of machines, it's about
consistency, it's about keeping the history of what happened to that
node. When a node is on a specific state you know what it's been
through so you can easily debug it (i.e an ACTIVE node means that it
passed through MANAGEABLE -> CLEAN* -> AVAILABLE -> DEPLOY* -> ACTIVE.
Even if some of the states are non-op for a given driver, it's a clear
path).

Think about our API, it's not that we don't allow vendors to add every
new features they have to the core part of the API because we don't
trust them or we think that their shiny features are not worthy. We
don't do that to make it consistent, to have an abstraction layer that
will work the same for all types of hardware.

I mean it when I said I want to have a fresh mind to read the proposal
this new work flow. But I rather read a technical explanation than an
emotional one. What I want to know for example is what it will look
like when one register a node in ACTIVE state directly? What about the
internal driver fields? What about the TFTP/HTTP environment that is
built as part of the DEPLOY process ? What about the ports in Neutron
? and so on...

Cheers,
Lucas