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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
