<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-08-27 18:43 GMT+02:00 Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Lucas Alvares Gomes's message of 2015-08-27 02:40:26 -0700:<br>
<div><div class="h5">> On Wed, Aug 26, 2015 at 11:09 PM, Julia Kreger<br>
> <<a href="mailto:juliaashleykreger@gmail.com">juliaashleykreger@gmail.com</a>> wrote:<br>
> > My apologies for not expressing my thoughts on this matter<br>
> > sooner, however I've had to spend some time collecting my<br>
> > thoughts.<br>
> ><br>
> > To me, it seems like we do not trust our users.  Granted,<br>
> > when I say users, I mean administrators who likely know more<br>
> > about the disposition and capabilities of their fleet than<br>
> > could ever be discovered or inferred via software.<br>
> ><br>
> > Sure, we have other users, mainly in the form of consumers,<br>
> > asking Ironic for hardware to be deployed, but the driver for<br>
> > adoption is who feels the least amount of pain.<br>
> ><br>
> > API versioning aside, I have to ask the community, what is<br>
> > more important?<br>
> ><br>
> > - An inflexible workflow that forces an administrator to<br>
> > always have a green field, and to step through a workflow<br>
> > that we've dictated, which may not apply to their operational<br>
> > scenario, ultimately driving them to write custom code to<br>
> > inject "new" nodes into the database directly, which will<br>
> > surely break from time to time, causing them to hate Ironic<br>
> > and look for a different solution.<br>
> ><br>
> > - A happy administrator that has the capabilities to do their<br>
> > job (and thus manage the baremetal node wherever it is in the<br>
> > operator's lifecycle) in an efficient fashion, thus causing<br>
> > them to fall in love with Ironic.<br>
> ><br>
><br>
> I'm sorry, I find the language used in this reply very offensive.<br>
> That's not even a real question, due the alternatives you're basically<br>
> asking the community "What's more important, be happy or be sad ? Be<br>
> efficient or not efficient?"<br>
><br>
<br>
<br>
</div></div>Funny, I find your response a bit offensive, as a user of Ironic who has<br>
been falling in love with it for a couple of years now, and is confused<br>
by the recent changes to the API that completely ignore me.<br>
<br>
I have _zero_ interest in this workflow. I want my nodes to be available<br>
as soon as I tell Ironic about them. You've added a step that makes no<br>
sense to me. Why not just let me create nodes in that state?<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It reminds me of a funny thing Monty Taylor pointed out in the Westin in<br>
Atlanta. We had to scramble to find our room keys to work the elevator,<br>
and upon unlocking the elevator, had to then push the floor for that<br>
room. As he pointed out "Why doesn't it just go to my floor now?"<br>
<br>
So, I get why you have the workflow, but I don't understand why you didn't<br>
include a short circuit for your existing users who are _perfectly happy_<br>
not having the workflow. So now I have to pin to an old API version to<br>
keep working the way I want, and you will eventually remove that API<br>
version, and I will proceed to grumble about why I have to change. <br></blockquote><div><br></div><div>Everything I know about API versioning tells me that we won't ever remove a single API version.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> It's not about an "inflexible workflow" which "dictates" what people<br>
> do making them "hate" the project. It's about finding a common pattern<br>
> for an work flow that will work for all types of machines, it's about<br>
> consistency, it's about keeping the history of what happened to that<br>
> node. When a node is on a specific state you know what it's been<br>
> through so you can easily debug it (i.e an ACTIVE node means that it<br>
> passed through MANAGEABLE -> CLEAN* -> AVAILABLE -> DEPLOY* -> ACTIVE.<br>
> Even if some of the states are non-op for a given driver, it's a clear<br>
> path).<br>
><br>
> Think about our API, it's not that we don't allow vendors to add every<br>
> new features they have to the core part of the API because we don't<br>
> trust them or we think that their shiny features are not worthy. We<br>
> don't do that to make it consistent, to have an abstraction layer that<br>
> will work the same for all types of hardware.<br>
><br>
> I mean it when I said I want to have a fresh mind to read the proposal<br>
> this new work flow. But I rather read a technical explanation than an<br>
> emotional one. What I want to know for example is what it will look<br>
> like when one register a node in ACTIVE state directly? What about the<br>
> internal driver fields? What about the TFTP/HTTP environment that is<br>
> built as part of the DEPLOY process ? What about the ports in Neutron<br>
> ? and so on...<br>
<br>
</span>Emotions matter to users. You're right that a technical argument helps<br>
us get our work done efficiently. But don't forget _why Ironic exists_.<br>
It's not for you to develop on, and it's not just for Nova to talk to.<br>
It's for your users to handle their datacenter in the wee hours without<br>
you to hold their hand. Make that hard, get somebody fired or burned<br>
out, and no technical argument will ever convince them to use Ironic<br>
again. <br></blockquote><div><br>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think I see the problem though. Ironic needs a new mission statement:<br>
<br>
    To produce an OpenStack service and associated libraries capable of<br>
    managing and provisioning physical machines, and to do this in a<br>
    security-aware and fault-tolerant manner.<br>
<br>
Mission accomplished. It's been capable of doing that for a long time.<br>
Perhaps the project should rethink whether _users_ should be considered<br>
in a new mission statement.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>--<br></div>-- Dmitry Tantsur<br><div>--<br></div></div></div>
</div></div>