confirmed 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
