Open Stack

Excerpts from melanie witt's message of 2018-08-21 15:05:00 -0700:
> On Tue, 21 Aug 2018 16:41:11 -0400, Doug Hellmann wrote:
> > Excerpts from melanie witt's message of 2018-08-21 12:53:43 -0700:
> >> 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?
> >>
> > 
> > Who are candidates to be members of a review team for the placement
> > repository after the code is moved out of openstack/nova?
> > 
> > How many of them are also members of the nova-core team?
> 
> I assume you pose this question in the proposed situation I described 
> where placement is a repo under compute. I expect the review team to be 

No, not at all. I'm trying to understand how you think a completely
separate team is going to cause problems. Because it seems like at
least a large portion, if not all, of the contributors want it, and
I need to have a very good reason for denying their request, if we
do. Right now, I understand that there are concerns, but I don't
understand why.

> > What do you think those folks are more interested in working on than the
> > things you listed as needing to be done to support the nova use cases?
> 
> I'm not thinking of anything specific here. At a high level, I don't see 
> how separating into two separate groups under separate leadership helps 
> us deliver the listed things for operators and users. I tend to think 
> that a unified group will be more successful at that.

OK. At the same time, I'm trying to understand why you have a hard
time believing a new team's priorities would not be aligned with
the nova team's priorities if, as it seems, a large percentage of
that new team would be made up of the same exact people.

> > What can they do to reassure you that they will work on the items
> > nova needs, regardless of the governance structure?
> 
> If they were separate groups, I don't see why the leadership of 
> placement would necessarily share goals and priorities with compute. I 
> think that is why it's much more difficult to get things done with two 
> separate groups, in general.

Most of the teams in the community seem to have a relatively easy time
coming to common agreement on priorities and goals, even when they are
not so closely related as the nova and placement teams would be. So I
guess I still don't see what the problem would be, and am looking for
more details, either about the concerns you all have or ways to
alleviate them.

> I want to reiterate again that the only thing I care about here is 
> delivering functionality that operators and users need. vGPUs, in 
> particular, has been highly sought after at a community-wide level, not 
> just from the compute community. I want to deliver the features that 
> people are depending on and IMHO, being a unified group helps that. I 
> don't see how being two separate groups helps that.

I don't think doing those things is mutually exclusive with solving,
or at least addressing, the underlying trust and self-governance
issues here, though. In fact, I think dealing with *that* is going
to make us all more effective at delivering the software, in the
long term because we will have cleared up what the expectations
between the two teams is.

Doug