Hi all! I am announcing my candidacy for PTL for the Ironic team for the Queens release cycle. In case you don't know me, I'm dtantsur on IRC. I started working on Ironic around late spring or summer 2014 (oh, time flies!), and has been dedicated full time to bare metal provisioning since then.
I am not going to surprise anyone, if I say that the Pike cycle was a difficult one. We've gone through removing four cores and through several iterations of re-prioritization. The team has done an amazing job keeping the pace - thank you all for that. This also required me to change my personal priorities for the cycle, concentrating more on keeping the project healthy and going. I hope I did not let you down. If you elect me, I would like to concentrate on the following efforts: * CI and testing improvements. This was on my agenda for Pike, and I'm not giving up on it. We have introduced multi-node jobs, a standalone job. I believe that the 3rd party CI have become more reliable since the beginning of the cycle. I would like to broaden the use of the standalone tests in the main and in 3rdparty CI to reduce the resource pressure and to be able to cover more important aspects of Ironic. I would like us to cover a few important testing gaps, such as testing adoption or root device hints. * Improve the prioritization process. I believe that we have been doing really well with our weekly priorities process. However, we have clearly had too many big items on our plate this cycle. That required an extensive de-prioritization in the end, leaving people frustrated. That also made it harder for less-of-a-priority changes, such as vendor-specific patches to get in. * Bug triaging. One of my PTL promises during the last election was to improve the bug handling process, and I apologize for not having done it. I would like to change it, and make sure that our bug backlog reduces instead of slowly growing. This may include better processes around incoming bug triaging, smarter dashboard and some automation, e.g. for handling old bugs. * Stabilization and paper cut bug fixing. This is related to the prioritization topic above. We've been chasing big stuff over a few cycles. That was absolutely justified, and we've landed several absolutely mind-blowing features, such as ironic-neutron integration or boot-from-volume. Now, I think, it's time to slow down a tiny bit, and think of the things that can make every day life managing an ironic deployment easier. Treating of the maintenance mode, reporting of cleaning progress, error messages and logging, just to name a few. Of course, this includes documentation for operators. As you know, I've spent some substantial time this cycle writing and refining installation and operation docs. With the documentation reform in place we have even more power over them - let's use it wisely. And as the last time, my significant goal will be not to get in a way of our wonderful team :) -- Dmitry Tantsur __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
