On Wed, 13 Mar 2019 09:41:14 -0500, Matt Riedemann <mriedemos@gmail.com> wrote:
On 3/13/2019 9:12 AM, Chris Dent wrote:
I mentioned this in IRC [1] too, but I think the candidates election statements [2,3] already try to explain why they think they would be a better PTL, so if there is going to be further discussion it needs to be based around specific questions or scenarios that you are concerned about. I think that would be very interesting and useful, so I'd encourage people to ask questions if they have them. But, expecting the candidates to extrapolate from what they've already done is too vague a request.
Well said Chris.
I'll take a shot at this. Maybe it's not so much a question as a statement. I'm looking for a PTL that is going to be not only available but involved in the major work going on in nova - and not just aware of it, but actually helping to push the code, be that through actual development of code or at least reviewing a lot of it. So I guess a way to phrase that into a question is what have you done in the last six months to demonstrate that you're not only available but helping, or better yet, leading to push the bigger things we're working on as a team, which could be stuff from our cycle themes [1] or the less tangible stuff like the placement extraction work, and how do you plan to continue that for the next six months?
[1] https://specs.openstack.org/openstack/nova-specs/priorities/stein-priorities...
First, I want to say that I don't believe it's about a "a better PTL," necessarily. Different people have different strengths and I think folks should select the person whose focus/interest/priorities they identify with more. To answer the question, in the last six months I worked on the spec and implementation of "counting quota usage from placement" at the request of our friends at CERN. This work was part of the "multi-cell operational enhancements" cycle theme, to make quota usage counting resilient in the presence of "down" or poor performing cells. I had proposed the idea in cycles past and had several discussions with the team about it, but ultimately ran into snags regarding lack of partitioning of allocations in placement. In the absence of specific interest from an operator, I put the idea on the back-burner. But, once the CERN folks let me know how important it was for them, I revived the spec and came up with a new proposal for working around the placement partitioning concern. It's not perfect, but as a team we found a compromise and I was able to push it forward. We landed the data migration piece of it this cycle. The actual counting part didn't make it and will have to wait for Train. I worked on cycle theme code and reviewed some cycle theme specs and code, but not as much as I wanted. I had taken on another feature earlier in the cycle (configurable maximum number of disk devices to attach to a single instance) and it took up much more of my time than I thought it would. And then the counting quota usage from placement spec/code came after that. Based on that experience, next cycle, I would finish up the counting quota usage code and then otherwise focus on pushing cycle theme content forward. My work from last cycle and cycles past shows that my primary focus is in keeping the Nova project healthy and stable, fixing bugs, working on fundamentals like cells, quotas, modernizing with Keystone unified limits and scope types, and making sure it continues to work well and upgrade smoothly for operators and end users. Cheers, -melanie