Open Stack

On Wed, 13 Mar 2019 09:41:14 -0500, Matt Riedemann <mriedemos at 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.html

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