<div dir="ltr">Hi all!<br><br>I'd like to announce my candidacy for the Bare Metal Provisioning (Ironic) PTL position.<br><br>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. <br>

<br>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!<div>

<br>So. Where do I see Ironic going next? <br><br>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.<br>

<br>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 ;)<div>

<br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>There are also many other features being talked about and/or requested and/or proposed ... so ...</div><div><br></div><div>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... :)<br>

</div></div><div><br></div><div>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.<br>

</div><div><br></div><div><br></div><div>Cheers!</div><div>Devananda</div></div>