Open Stack

> The reshaper code
> is still going through code review, then next we have the integration to
> do.

To clarify: we're doing the integration in concert with the API side.
Right now the API side patches [1][2] are in series underneath the nova
side [3].

In a placement-in-its-own-repo world, the only difference would have
been that these would be separate series with a Depends-On linking them,
and would require a placement release. (In fact, with a couple of
additional "placement cores", the API side could have been completed
faster and we might have landed the whole in Rocky.)

In a placement-under-separate-governance world, I contend there would
have been *zero* additional difference. Speculating on who the
"placement team" would be, the exact same people would have been present
at the hangouts and participating in the spec and code reviews.

[1] https://review.openstack.org/#/c/576927/
[2] https://review.openstack.org/#/c/585033/
[3] https://review.openstack.org/#/c/584598/ and up

> I think going through this
> integration would be best done *before* extraction to a new repo.

Agree. That could happen this week with some focused reviewing.

> I am OK with the idea of doing the extraction first, if that is
> what most people want to do.

Sweet. To close on this part of the discussion, is there anyone who
still objects to doing at least the repository-and-code part of the
extraction now?

> 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.

Sorry, I'm confused - are we talking about NUMA cells or cellsv2 cells?
If the latter, what additional placement-side support is needed to
support it?

> Shared storage support is something
> operators have badly needed for years now and was envisioned to be
> solved with placement.

Again, I'm pretty sure the placement side work for this is done, or very
close to it; the remaining work is on the nova side.

But regardless, let's assume both of the above require significant
placement work in close coordination with nova for specs, design,
implementation, etc. How would separating governance have a negative
impact on that? As for reshaper, it would be all the same people in the
room. As Doug says:

> 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?
>
> What can they do to reassure you that they will work on the items
> nova needs, regardless of the governance structure?

More...

> 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?

You answered your own question. If operators need a thing that involves
placement and nova, placement and nova have a shared interest in making
it happen. s/placement|nova/$openstack_project/. It's what we're about...

> separate goals and priorities

...because those priorities should largely overlap and be aligned with
OpenStack's goals and priorities, right?

> 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?

This brings us to another part of the discussion I think we can close on
right now. I don't think I've heard any objections to: "The initial
placement-core team should be a superset of the nova-core team." Do we
have a consensus on that?

(Deferring discussion of who the additional members ought to be. That
probably needs its own thread and/or a different audience.)

-efried