<div dir="ltr"><div id="gmail-magicdomid628" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">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:</span></div><div id="gmail-magicdomid208" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">    $ pip install -U placement</span></div><div id="gmail-magicdomid217" class="gmail-ace-line"><br></div><div id="gmail-magicdomid1699" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">I would prefer "placement" to be a project driven by diverse people interested by Infrastructure resources placement and not just nova.</span></div><div id="gmail-magicdomid1700" class="gmail-ace-line"><br></div><div id="gmail-magicdomid1707" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">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.</span></div><div id="gmail-magicdomid1708" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">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.</span></div><div id="gmail-magicdomid1752" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">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.</span></div><div id="gmail-magicdomid1754" class="gmail-ace-line"><br></div><div id="gmail-magicdomid1763" class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">Let's reset a little bit and give these people a chance here.</span></div><div class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">Let's create this independent team.</span></div><div class="gmail-ace-line"><span class="gmail-author-a-0lz72z4z81zg45ez81zi0z73z1bs">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.<br></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 21, 2018 at 8:55 AM Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matt Riedemann wrote:<br>
> [...]<br>
> Regarding microversions I was mostly thinking of the various times I've <br>
> been asked in the placement channel if something warrants a microversion <br>
> or if we can just bug fix it in, like microversion 1.26. I then <br>
> generally feel like I need to be defensive when I say, "yes it's a <br>
> behavior change in the API so it should." That makes me question how <br>
> stringent others would be about upholding interoperability concerns if I <br>
> weren't around. [...]<br>
<br>
The issue with that kind of distrust by default is that it's not <br>
sustainable... In a large project you can't have every individual review <br>
everything because they trust noone else.<br>
<br>
That is why in OpenStack we instituted a culture of "trust by default, <br>
then escalate to PTL or TC if shit ever hits the fan". And the fact is, <br>
the PTL (at team level) or the TC (between teams) rarely had to <br>
arbitrate conflicts, because there aren't so many conflicts that are <br>
escalated rather than solved by consensus at the lower level.<br>
<br>
Restoring "trust by default" between placement and the rest of Nova <br>
seems to be the root of the problem here. In a community, it's generally <br>
done by documenting general expectations and shared understandings, so <br>
that you create a common culture and trust by default people to apply it.<br>
<br>
What would you suggest we do to improve that in this specific case?<br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>