Open Stack

Hi all!

I'd like to announce my candidacy for the Bare Metal Provisioning (Ironic)
PTL position.

I've been involved with bare metal provisioning for the last two years,
before it was even in Nova. I led the work on nova.virt.baremetal driver
throughout Grizzly and Havana cycles, and at the Havana summit, I proposed
splitting it all out of Nova. Ironic is solving a
significantly-different-enough problem that it required a different
architecture, one that supports and abstracts heterogeneous hardware
deployments, that models physical (rather than virtual) workloads, and that
has no single point of failure in the management plane.

I believe that we made great progress during the Icehouse cycle. When I
look at the problems we're solving today, they're vastly different than
what we were solving six months ago. We have added a lot of features, but I
think our progress is best shown by the number of developers who have, in
the last few weeks, been testing Ironic by simply starting devstack and
TripleO. This may not sound like much -- after all, shouldn't it be as
simple as starting a few services and creating a database? In our case, no.
For Ironic to function, even in a developer sandbox, it requires
interaction with Nova, Neutron, Glance, and Keystone. I want to especially
thank everyone who's worked on the integration and testing efforts over the
last few months!

So. Where do I see Ironic going next?

Most importantly, we need to continue the CI effort. Testing has shown that
it is easy to trip up the nova.virt.ironic driver, and that's a critical
piece. As a project aiming to deprecate the nova.virt.baremetal driver,
thorough CI testing of the nova.virt.ironic driver to demonstrate its
stability is a requirement for graduation. Of course, it's also important
to our users, who will leverage nova for the actual provisioning of
hardware resources.

I would like to grow the review team considerably. I think it was
reasonable, when we had no integration tests and so testing required
in-depth knowledge of the code, to keep the core reviewer team limited to
core developers. That is no longer the case. I'd like to thank everyone on
the core team for putting in some long hours, especially over the last two
months as we worked through the backlog leading up to I-3 and RC1. As
awesome as it was to hang out with all of you, I think we'd all benefit
from scale-out rather than scale-up ;)

Speaking of reviews, we had several features that were targeted to Icehouse
but did not get completed in time, and I believe this has more to do with
reviewer bandwidth than anything else. I would like to revive the serial
console support, which was not quite done for Icehouse, and add Ceilometer
notifications for hardware status and ulitization, for which an API has
been spec'd out and the draft implementation needs to be revived.

I would also like to add the HP iLO driver, and help both SeaMicro and HP
bring up third-party CI systems by the J-2 milestone. I believe that vendor
support is extremely beneficial to Ironic, and third-party CI is essential
to supporting vendor drivers. As we continue fleshing out our integration
testing, we need to ensure that it can be pivoted to test a vendor's driver.

We have all forseen the need for a more featureful "deploy ramdisk", and at
the sprint in February, Rackspace presented their work. All the teams
present discussed it at length and felt it was a good starting point, so
teeth was renamed ironic-python-agent and moved under the program. Many of
the most requested features will not be possible without this agent; I hope
to see Ironic begin using it as the reference deploy agent in Juno.

There are also many other features being talked about and/or requested
and/or proposed ... so ...

After going through release process in Icehouse, and holding the project to
it even though we were not part of the integrated release, I have a better
sense of how the release process will affect project development pace in
Juno. While it delayed the inclusion of several features, I believe the
result is more stable than it would have been otherwise. I would like to
avoid that situation again by ensuring integration testing of all new
features that are added, including those that require physical hardware to
validate and third-party drivers. This is going to be a challenging problem
to solve, and will require support from hardware vendors... :)

In closing, leading the Bare Metal Provisioning program has been an
incredible opportunity, and I hope to continue working on it for some time
to come! I would like to thank everyone that has worked with me on this
project -- I am continually learning from all of you, and appreciative for
the constructive dialogues that we have.


Cheers!
Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/721f5365/attachment.html>