Open Stack

Excerpts from Lucas Alvares Gomes's message of 2015-08-27 02:40:26 -0700:
> 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?"
> 


Funny, I find your response a bit offensive, as a user of Ironic who has
been falling in love with it for a couple of years now, and is confused
by the recent changes to the API that completely ignore me.

I have _zero_ interest in this workflow. I want my nodes to be available
as soon as I tell Ironic about them. You've added a step that makes no
sense to me. Why not just let me create nodes in that state?

It reminds me of a funny thing Monty Taylor pointed out in the Westin in
Atlanta. We had to scramble to find our room keys to work the elevator,
and upon unlocking the elevator, had to then push the floor for that
room. As he pointed out "Why doesn't it just go to my floor now?"

So, I get why you have the workflow, but I don't understand why you didn't
include a short circuit for your existing users who are _perfectly happy_
not having the workflow. So now I have to pin to an old API version to
keep working the way I want, and you will eventually remove that API
version, and I will proceed to grumble about why I have to change.

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

Emotions matter to users. You're right that a technical argument helps
us get our work done efficiently. But don't forget _why Ironic exists_.
It's not for you to develop on, and it's not just for Nova to talk to.
It's for your users to handle their datacenter in the wee hours without
you to hold their hand. Make that hard, get somebody fired or burned
out, and no technical argument will ever convince them to use Ironic
again.

I think I see the problem though. Ironic needs a new mission statement:

    To produce an OpenStack service and associated libraries capable of
    managing and provisioning physical machines, and to do this in a
    security-aware and fault-tolerant manner.

Mission accomplished. It's been capable of doing that for a long time.
Perhaps the project should rethink whether _users_ should be considered
in a new mission statement.