[nova][ptl][election] Start the battle
melwittt at gmail.com
Fri Mar 15 02:42:51 UTC 2019
On Wed, 13 Mar 2019 09:41:14 -0500, Matt Riedemann <mriedemos at gmail.com>
> On 3/13/2019 9:12 AM, Chris Dent wrote:
>> I mentioned this in IRC  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  or the less
> tangible stuff like the placement extraction work, and how do you plan
> to continue that for the next six months?
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
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.
More information about the openstack-discuss