Open Stack

On 08/27/2015 11:40 AM, Lucas Alvares Gomes wrote:
> 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...

I agree with everything Lucas said.

I also want to point that it's completely unrealistic to expect even 
majority of Ironic users to have at least some idea about how Ironic 
actually works. And definitely not all our users are Ironic developers.

I routinely help people who never used Ironic before, and they don't 
have problems with running 1, 2, 10 commands, if they're written in the 
documentation and clearly explained. What they do have problems with is 
several ways of doing the same thing, with different ways being broken 
under different conditions.

>
> Cheers,
> Lucas
>
> __________________________________________________________________________
> 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
>