Open Stack

Hi all,

I would like to announce my candidacy for the PTL role of the Bare Metal
Provisioning program.

I have been the PTL of Ironic since I began the project at the Havana summit,
and I am partly to blame for the baremetal driver that Ironic was forked from.
(If you've touched that code, you will share in my joy when it is finally
deleted from Nova!) In that time, I have been delighted to work with many
people whose knowledge of the innards of hardware management and provisioning
is far deeper than mine, and I have come to rely on their experience to inform
the project's course. Without each of you, Ironic would not be what it is
today.  Thank you!

As we move into the Kilo cycle, I would like us to remember this purpose:
provisioning workloads on physical machines, driven by the principles of cloud
computing, which I'll sum up as: abstraction, automation, and elasticity. Where
a proposed feature would violate any of these principles, I do not believe it
will benefit the project.

In the Juno cycle, we have seen a large (but not unexpected) influx of hardware
drivers. This, I believe, is a result of the stability of the code and the
narrow focus of the core of the project. This focus has discouraged certain
uses and, perhaps, alienated some contributors whose needs were not well served
-- and I'm OK with that. I believe that all OpenStack projects (like all
software) must have a clear and limited purpose, and, especially early in their
life cycle, resist scope creep. There is plenty of room for neighboring
projects within the "bare metal" space.

On the one hand, vendors are adding functionality to their drivers that
extends beyond the existing core capabilities. We must work with them to
stabilize and abstract this into common APIs.

On the other hand, we currently require operators to prepare a machine before
it can be used with Ironic or when changing the role it fulfils. We have seen a
lot of interest in expanding the project's scope to increase automation of
these "prepartion" and "decommissioning" phases, and I believe we will see
incremental progress here during Kilo through the exposure of hardware
capabilities that may be changed just-in-time during provisioning. The topics
of discovery and inventory management also consistently arises, and we've
discussed these several times recently. As a result, my position on this has
changed over the last two years - I no longer believe this has a place within a
*provisioning* service, but it is a necessary component in fleet management.
While I believe that Ironic can already be integrated with such systems, I do
not know of any agentless inventory management systems in the open source
ecosystem.

We must continue to integrate with other OpenStack projects, and the ongoing
Big Tent discussion does not change our goals here (though it may change the
processes we go through to get there). I believe that Horizon integration will
be very important in Kilo, as well as better operational monitoring through
statsd / Ceilometer integration, and we should add a notification bus between
Ironic and Nova to reduce the time lag before resource changes are visible to
users.

I would also like to promote a separate effort to use Ironic in a stand-alone
fashion.  I believe this will meet the needs of an important set of users who
do not require the full abstraction which OpenStack provides.

I believe we also need to grow the breadth of knowledge within the core team
through hands-on usage of Ironic in production deployments. Rackspace's
contributions based on running the OnMetal service during Juno have been
immeasurably beneficial to the project, and I would like more direct operator
input during Kilo.

Sincerely,
Devananda