[nova][ptl][election] Start the battle
We are having two excellent PTL candidates now, making it very difficult for me - and probably others - to decide between them. So I would like to ask the candidates for some statements explaining why they would be the better PTL, lest the election ends up in a tie.
On Wed, 13 Mar 2019, Jens Harbott wrote:
We are having two excellent PTL candidates now, making it very difficult for me - and probably others - to decide between them. So I would like to ask the candidates for some statements explaining why they would be the better PTL, lest the election ends up in a tie.
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. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2... [2] mel: https://git.openstack.org/cgit/openstack/election/plain/candidates/train/Nov... [3] eric: https://git.openstack.org/cgit/openstack/election/plain/candidates/train/Nov... -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
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... -- Thanks, Matt
Thanks for opening this up, Jens; and thanks Chris and Matt for crisping up the ask.
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?
In my view, the main [1] vehicle of progress in Nova is Placement. I have been working tirelessly for the past six (or 18) months to help shape Placement into being able to support major Nova use cases; and I have been working likewise in Nova to take advantage of that functionality. For quite a while, Placement was adding features far faster than Nova could use them. Around Queens, we started putting a bunch of framework in Nova to *prepare* for making use of things like nested providers [2][3], but it has only been in Stein that Nova features have been implemented which actually use them. This includes VGPU, which prompted the reshaper effort [4]; and bandwidth resource providers [5], a huge multi-project multi-cycle effort that is finally landing. This is just the tip of the iceberg. We have a lot of "Placement exploitation" work remaining, including (not a complete list, and in no particular order): - Making sharing providers work. Famously, if your host's root disk resource lives on shared storage, the reporting of the amount of disk in your cloud is wrong by a factor of <number of hosts sharing that storage>. This was one of the main reasons Placement was created. We made a good effort to fix a piece of this in Rocky [6], but didn't quiite get there. This is something I'd like to see finally get some real traction in Train. - Modeling NUMA. While nested providers seem to be ideal for representing resources affined to NUMA cells, a) we haven't done it yet - hopefully [7] will be a solid step in that direction; and b) there are still some design gaps, such as inter-provider affinity, that we have discussed repeatedly but never closed on. I would like to be able to move those forward and break the "analysis paralysis". - Accelerators, or more generally, "PCI Passthrough should DIAF". We're reaching tentative tentacles into representing accelerators in Placement (cf. VGPUs above), but a more generic and far-reaching solution is called for. I want to push for the adoption of Cyborg - another thing we've discussed several times and needs the thrash cycle broken - as a big step in that direction. Hopefully the above goes some way toward exemplifying my record of and commitment to: - Past: Making Placement and Nova ready for... - Present: Significant progress on real features; and - Future: Breaking the cycle of design churn to make forward progress. This is really important. Some problems are hard, and don't have perfect solutions. We need to be able to reach a consensus (which often does *not* mean unanimous agreement) on which imperfect solution is least painful and DO IT. Thanks, Eric [1] obviously not the only; lots of the priority/themed work such as cells touches Placement marginally or not at all [2] https://review.openstack.org/#/q/topic:bp/nested-resource-providers [3] https://review.openstack.org/#/q/topic:bp/granular-resource-requests [4] https://review.openstack.org/#/q/topic:bp/reshape-provider-tree [5] https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider [6] https://review.openstack.org/#/c/560459/ [7] https://review.openstack.org/#/c/552924/
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
participants (5)
-
Chris Dent
-
Eric Fried
-
Jens Harbott
-
Matt Riedemann
-
melanie witt