On Tue, 21 Aug 2018 14:55:26 -0600, Chris Friesen wrote:
On 08/21/2018 01:53 PM, melanie witt wrote:

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?

As someone who is not involved in the governance of nova, this seems like kind
of an odd statement for an open-source project.

  From the outside, it seems like there is a fairly small pool of active
placement developers.  And either the placement developers are willing to
implement the capabilities desired by compute or else they're not.  And if
they're not, I don't see how being under compute governance would resolve that
since the only official hard leverage the compute governance has is refusing to
review/merge placement patches (which wouldn't really help implement compute's
desires anyways).

I'm not sure I follow. As of now, placement developers are participating in the same priorities and goals setting as the rest of compute, each cycle. We discuss work that needs to be done and how to prioritize it, in the context of compute. We are one group.

If we separate into two different groups, all of the items I discussed in my previous reply will become cross-project efforts. To me, this means that the placement group will have their own priorities and goal setting process and if their priorities and goals happen to align with ours on certain items, we can agree to work on those in collaboration. But I won't make assumptions about how much alignment we will have. The placement group, as a hypothetical example, won't necessarily find helping us fix issues with compute functionality like vGPUs as important as we do, if we need additional work in placement to support it.

That's how I'm thinking about it, from a practical standpoint. I'm thinking about what it will look like delivering the functionality I discussed in my previous reply, for operators and users. I think it helps to be one group.

-melanie




__________________________________________________________________________
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

Reply via email to