Open Stack

On Tue, 21 Aug 2018 06:50:56 -0500, Matt Riedemann wrote:
> At this point, I think we're at:
> 
> 1. Should placement be extracted into it's own git repo in Stein while
> nova still has known major issues which will have dependencies on
> placement changes, mainly modeling affinity?
> 
> 2. If we extract, does it go under compute governance or a new project
> with a new PTL.
> 
> As I've said, I personally believe that unless we have concrete plans
> for the big items in #1, we shouldn't hold up the extraction. We said in
> Dublin we wouldn't extract to a new git repo in Rocky but we'd work up
> to that point so we could do it in Stein, so this shouldn't surprise
> anyone. The actual code extraction and re-packaging and all that is
> going to be the biggest technical issue with all of this, and will
> likely take all of stein to complete it after all the bugs are shaken out.
> 
> For #2, I think for now, in the interim, while we deal with the
> technical headache of the code extraction itself, it's best to leave the
> new repo under compute governance so the existing team is intact and we
> don't conflate the people issue with the technical issue at the same
> time. Get the hard technical part done first, and then we can move it
> out of compute governance. Once it's in its own git repo, we can change
> the core team as needed but I think it should be initialized with
> existing nova-core.

I'm in support of extracting placement into its own git repo because 
Chris has done a lot of work to reduce dependencies in placement and 
moving it into its own repo would help in not having to keep chasing 
that. As has been said before, I think all of us agree that placement 
should be separate as an end goal. The question is when to fully 
separate it from governance.

It's true that we don't have concrete plans for affinity modeling and 
shared storage modeling. But I think we do have concrete plans for vGPU 
enhancements (being able to have different vGPU types on one compute 
host and adding support for traits). vGPU support is an important and 
highly sought after feature for operators and users, as we witnessed at 
the last Summit in Vancouver. vGPU support is currently using a flat 
resource provider structure that needs to be migrated to nested in order 
to do the enhancement work, and that's how the reshaper work came about. 
(Reshaper work will migrate a flat resource provider structure to a 
nested one.)

We have the nested resource provider support in placement but we need to 
integrate the Nova side, leveraging the reshaper code. The reshaper code 
is still going through code review, then next we have the integration to 
do. I think things are bound to break when we integrate it, just because 
nothing is ever perfect, as much as we scrutinize it and the real test 
is when we start using it for real. I think going through this 
integration would be best done *before* extraction to a new repo. But 
given that there is never a "good" time to extract something to a new 
repo, I am OK with the idea of doing the extraction first, if that is 
what most people want to do.

What I'm concerned about on the governance piece is how things look as 
far as project priorities between the two projects if they are split. 
Affinity modeling and shared storage support are compute features 
OpenStack operators and users need. Operators need affinity modeling in 
the placement is needed to achieve parity for affinity scheduling with 
multiple cells. That means, affinity scheduling in Nova with multiple 
cells is susceptible to races and does *not* work as well as the 
previous single cell support. Shared storage support is something 
operators have badly needed for years now and was envisioned to be 
solved with placement.

Given all of that, I'm not seeing how *now* is a good time to separate 
the placement project under separate governance with separate goals and 
priorities. If operators need things for compute, that are well-known 
and that placement was created to solve, how will placement have a 
shared interest in solving compute problems, if it is not part of the 
compute project?

I understand that placement wants to appeal to more consumers (by way of 
splitting governance) but at present, Nova is the only consumer. And by 
consumer, I mean Nova is the only one consuming data *from* placement 
and relying on it to do something. I don't understand why it's really 
important *right now* to separate priorities before there are other 
viable consumers. I would like to share priorities and goals, for now, 
under the compute program to best serve operators and users in solving 
the specific problems I've mentioned in my replies to this thread.

Best,
-melanie