On 24/09/14 04:28 PM, Devananda van der Veen wrote:
> 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
> _______________________________________________
> OpenStack-dev mailing list

Attachment: signature.asc
Description: OpenPGP digital signature

OpenStack-dev mailing list

Reply via email to