2015-08-27 18:43 GMT+02:00 Clint Byrum <cl...@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 > > <juliaashleykre...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -- -- Dmitry Tantsur --
__________________________________________________________________________ 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