confirmed On 04/01/2014 05:30 PM, Devananda van der Veen wrote: > 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 > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
