On 08/27/2015 11:40 AM, Lucas Alvares Gomes wrote:
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?"
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
