Open Stack

2015-08-27 18:43 GMT+02:00 Clint Byrum <clint at fewbar.com>:

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

Because we don't have a test on a users' experience level in OpenStack in
our node-create command ;) It won't distinguish between you, knowing
precisely what you're doing, and a confused user who picked a wrong command
and is in one step from shooting his/her leg.


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

Everything I know about API versioning tells me that we won't ever remove a
single API version.


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

You care only about users at your technical level in OpenStack. For other
(and the majority of) users the situation is the opposite: they want to be
told that they've screwed their SSH credentials (and they *constantly* do)
as soon as it is possible. If they are not, their nodes, for example, will
silently go into maintenance, and then nova will return cryptic "no valid
host found" error.


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

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



-- 
--
-- Dmitry Tantsur
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/21987e97/attachment.html>