[openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

Emilien Macchi emilien at redhat.com
Tue Aug 21 13:29:50 UTC 2018


If I would be a standalone consummer of OpenStack Placement (e.g. I only
run cinder or ironic to manage volume / baremetal), and I had to run
something like:
    $ pip install -U placement

I would prefer "placement" to be a project driven by diverse people
interested by Infrastructure resources placement and not just nova.

In other words, I would be afraid of seeing this project owned by the nova
team since the scope of placement seems to go beyond compute. Instead I
would be at ease to see a separated PTL and core team, who closely work
with OpenStack projects consuming placement service.
People writting placement's code would *own* this project, and decide of
their future. They would serve projects like nova, cinder, maybe ironic one
day, etc.
By making this team more independent, I believe they could build trust in
our community, which is something we desperately need nowadays and have
been encouraging over the last years. I have an high level of confidence
that this new team would be smart enough to collaborate when it comes to
code design decisions, no matter what happened in the past.

Let's reset a little bit and give these people a chance here.
Let's create this independent team.
I believe we could even write down a (short) vision for placement, and a
(short) mission statement, then we can set expectations for the near future.

On Tue, Aug 21, 2018 at 8:55 AM Thierry Carrez <thierry at openstack.org>
wrote:

> Matt Riedemann wrote:
> > [...]
> > Regarding microversions I was mostly thinking of the various times I've
> > been asked in the placement channel if something warrants a microversion
> > or if we can just bug fix it in, like microversion 1.26. I then
> > generally feel like I need to be defensive when I say, "yes it's a
> > behavior change in the API so it should." That makes me question how
> > stringent others would be about upholding interoperability concerns if I
> > weren't around. [...]
>
> The issue with that kind of distrust by default is that it's not
> sustainable... In a large project you can't have every individual review
> everything because they trust noone else.
>
> That is why in OpenStack we instituted a culture of "trust by default,
> then escalate to PTL or TC if shit ever hits the fan". And the fact is,
> the PTL (at team level) or the TC (between teams) rarely had to
> arbitrate conflicts, because there aren't so many conflicts that are
> escalated rather than solved by consensus at the lower level.
>
> Restoring "trust by default" between placement and the rest of Nova
> seems to be the root of the problem here. In a community, it's generally
> done by documenting general expectations and shared understandings, so
> that you create a common culture and trust by default people to apply it.
>
> What would you suggest we do to improve that in this specific case?
>
> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180821/8e0d303b/attachment.html>


More information about the OpenStack-dev mailing list