Open Stack

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