Open Stack

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140924/4d4df2b3/attachment.pgp>