<div dir="ltr"><div>+1 <br>Devananda is a great PLT. It is his vision that has and is driving Ironic's rapid development.<br><br><br></div>Chris Krelle<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Sep 24, 2013 at 11:04 AM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Hi!</p>
<p dir="ltr">I would like to nominate myself for the OpenStack Bare Metal Provisioning (Ironic) PTL position. </p>
<p dir="ltr">I have been working with OpenStack for over 18 months, and was a scalability and performance consultant at Percona for four years prior. Since '99, I have worked as a developer, team lead, database admin, and linux systems architect for a variety of companies.</p>


<p dir="ltr">I am the current PTL of the Bare Metal Provisioning (Ironic) program, which began incubation during Havana. In collaboration with many fine folks from HP, NTT Docomo, USC/ISI, and VirtualTech, I worked extensively on the Nova Baremetal driver during the Grizzly cycle. I also helped start the TripleO program, which relies heavily on the baremetal driver to achieve its goals. During the Folsom cycle, I led the effort to improve Nova's DB API layer and added devstack support for the OpenVZ driver. Through that work, I became a member of nova-core for a time, though my attention has shifted away from Nova more recently.</p>


<p dir="ltr">Once I had seen nova-baremetal and TripleO running in our test environment and began to assess our longer-term goals (eg, HA, scalability, integration with other OpenStack services), I felt very strongly that bare metal provisioning was a separate problem domain from Nova and would be best served with a distinct API service and a different HA framework than what is provided by Nova. I circulated this idea during the last summit, and then proposed it to the TC shortly thereafter.</p>


<p dir="ltr">During this development cycle, I feel that Ironic has made significant progress. Starting from the initial "git bisect" to retain the history of the baremetal driver, I added an initial service and RPC framework, implemented some architectural pieces, and left a lot of #TODO's. Today, with commits from 10 companies during Havana (*) and integration already underway with devstack, tempest, and diskimage-builder, I believe we will have a functional release within the Icehouse time frame.</p>


<p dir="ltr">I feel that a large part of my role as PTL has been - and continues to be - to gather ideas from a wide array of individuals and companies interested in bare metal provisioning, then translate those ideas into a direction for the program that fits within the OpenStack ecosystem. Additionally, I am often guiding compromise between the long-term goals, such as firmware management, and the short-term needs of getting the project to a fully-functional state. To that end, here is a brief summary of my goals for the project in the Icehouse cycle.</p>


<p dir="ltr">* API service and client library (likely finished before the summit)<br>
* Nova driver (blocked, depends on ironic client library)<br>
* Finish RPC bindings for power and deploy management<br>
* Finish merging bm-deploy-helper with Ironic's PXE driver<br>
* PXE boot integration with Neutron<br>
* Integrate with TripleO / TOCI for automated testing<br>
* Migration script for existing deployments to move off the nova-baremetal driver<br>
* Fault tolerance of the ironic-conductor nodes<br>
* Translation support<br>
* Docs, docs, docs!</p>
<p dir="ltr">Beyond this, there are many long-term goals which I would very much like to facilitate, such as:</p>
<p dir="ltr">* hardware discovery<br>
* better integration with SDN capable hardware<br>
* pre-provisioning tools, eg. management of bios, firmware, and raid config, hardware burn-in, etc.<br>
* post-provisioning tools, eg. secure-erase<br>
* boot from network volume<br>
* secure boot (protect deployment against MITM attacks)<br>
* validation of signed firmware (protect tenant against prior tenant)</p>
<p dir="ltr">Overall, I feel honored to be working with so many talented individuals across the OpenStack community, and know that there is much more to learn as a developer, and as a program lead.</p>
<p dir="ltr">(*)<br>
<a href="http://www.stackalytics.com/?release=havana&metric=commits&project_type=All&module=ironic" target="_blank">http://www.stackalytics.com/?release=havana&metric=commits&project_type=All&module=ironic</a></p>


<p dir="ltr"><a href="http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt" target="_blank">http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt</a><br>
<a href="http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt" target="_blank">http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt</a><br></p>
<p dir="ltr">--<br>
Devananda</p>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>