63 lines
3.0 KiB
Plaintext
63 lines
3.0 KiB
Plaintext
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
|