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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev