+1!
Best Regards, ----------------------------- Sun Jing(孙靖, sjing) Wentian Jiang <went...@unitedstack.com> 2013/09/25 23:02 Please respond to OpenStack Development Mailing List <openstack-dev@lists.openstack.org> To OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, cc Subject Re: [openstack-dev] [Ironic] PTL nomination +1 Devananda On Wed, Sep 25, 2013 at 10:44 PM, Chris K <nobody...@gmail.com> wrote: > +1 > Devananda is a great PLT. It is his vision that has and is driving Ironic's > rapid development. > > > Chris Krelle > > > On Tue, Sep 24, 2013 at 11:04 AM, Devananda van der Veen > <devananda....@gmail.com> wrote: >> >> Hi! >> >> I would like to nominate myself for the OpenStack Bare Metal Provisioning >> (Ironic) PTL position. >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> * API service and client library (likely finished before the summit) >> * Nova driver (blocked, depends on ironic client library) >> * Finish RPC bindings for power and deploy management >> * Finish merging bm-deploy-helper with Ironic's PXE driver >> * PXE boot integration with Neutron >> * Integrate with TripleO / TOCI for automated testing >> * Migration script for existing deployments to move off the nova-baremetal >> driver >> * Fault tolerance of the ironic-conductor nodes >> * Translation support >> * Docs, docs, docs! >> >> Beyond this, there are many long-term goals which I would very much like >> to facilitate, such as: >> >> * hardware discovery >> * better integration with SDN capable hardware >> * pre-provisioning tools, eg. management of bios, firmware, and raid >> config, hardware burn-in, etc. >> * post-provisioning tools, eg. secure-erase >> * boot from network volume >> * secure boot (protect deployment against MITM attacks) >> * validation of signed firmware (protect tenant against prior tenant) >> >> 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. >> >> (*) >> >> http://www.stackalytics.com/?release=havana&metric=commits&project_type=All&module=ironic >> >> http://russellbryant.net/openstack-stats/ironic-reviewers-30.txt >> http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt >> >> -- >> Devananda >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Wentian Jiang UnitedStack Inc. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
