<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-08-18 20:25 GMT+08:00 Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 17 Aug 2018, Doug Hellmann wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we ignore the political concerns in the short term, are there<br>
other projects actually interested in using placement? With what<br>
technical caveats? Perhaps with modifications of some sort to support<br>
the needs of those projects?<br>
</blockquote>
<br></span>
I think ignoring the political concerns (in any term) is not<br>
possible. We are a group of interacting humans, politics are always<br>
present. Cordial but active debate to determine the best course of<br>
action is warranted.<br>
<br>
(tl;dr: Let's have existing and potential placement contributors<br>
decide its destiny.)<br>
<br>
Five topics I think are relevant here, in order of politics, least<br>
to most:<br>
<br>
1. Placement has been designed from the outset to have a hard<br>
contract between it and the services that use it. Being embedded<br>
and/or deeply associated with one other single service means that<br>
that contract evolves in a way that is strongly coupled. We made<br>
placement have an HTTP API, not use RPC, and not produce or consume<br>
notifications because it is supposed to be bounded and independent.<br>
Sharing code and human management doesn't enable that. As you'll<br>
read below, placement's progress has been overly constrained by<br>
compute.<br>
<br>
2. There are other projects actively using placement, not merely<br>
interested. If you search codesearch.o.o for terms like "resource<br>
provider" you can find them. But to rattle off those that I'm aware<br>
of (which I'm certain is an incomplete list):<br>
<br>
* Cyborg is actively working on using placement to track FPGA<br>
e.g., <a href="https://review.openstack.org/#/c/577438/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/577438/</a><br>
<br>
* Blazar is working on using them for reservations:<br>
<a href="https://review.openstack.org/#/q/status:open+project:openstack/blazar+branch:master+topic:bp/placement-api" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+project:opensta<wbr>ck/blazar+branch:master+topic:<wbr>bp/placement-api</a><br>
<br>
* Neutron has been reporting to placement for some time and has work<br>
in progress on minimum bandwidth handling with the help of<br>
placement:<br>
<a href="https://review.openstack.org/#/q/status:open+project:openstack/neutron-lib+branch:master+topic:minimum-bandwidth-allocation-placement-api" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+project:opensta<wbr>ck/neutron-lib+branch:master+<wbr>topic:minimum-bandwidth-<wbr>allocation-placement-api</a><br>
<br>
* Ironic uses resource classes to describe types of nodes<br>
<br>
* Mogan (which may or may not be dead, not clear) was intending to<br>
track nodes with placement:<br>
<a href="http://git.openstack.org/cgit/openstack/mogan-specs/tree/specs/pike/approved/track-resources-using-placement.rst" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/mogan-specs/tree/spe<wbr>cs/pike/approved/track-resourc<wbr>es-using-placement.rst</a><br>
<br>
* Zun is working to use placement for "unified resource management":<br>
<a href="https://blueprints.launchpad.net/zun/+spec/use-placement-resource-management" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/zun/+spec/use-placement-res<wbr>ource-management</a><br>
<br>
* Cinder has had discussion about using placement to overcome race<br>
conditions in its existing scheduling subsystem (a purpose to<br>
which placement was explicitly designed).<br>
<br>
3. Placement's direction and progress is heavily curtailed by the<br>
choices and priorities that compute wants or needs to make. That<br>
means that for the past year or more much of the effort in placement<br>
has been devoted to eventually satisfying NFV use cases driven by<br>
"enhanced platform awareness" to the detriment of the simple use<br>
case of "get me some resource providers". Compute is under a lot of<br>
pressure in this area, and is under-resourced, so placement's<br>
progress is delayed by being in the (necessarily) narrow engine of<br>
compute. Similarly, computes's overall progress is delayed because a<br>
lot of attention is devoted to placement.<br>
<br>
I think the relevance of that latter point has been under-estimated<br>
by the voices that are hoping to keep placement near to nova. The<br>
concern there has been that we need to continue iterating in concert<br>
and quickly. I disagree with that from two angles. One is that we<br>
_will_ continue to work in concert. We are OpenStack, and presumably<br>
all the same people working on placement now will continue to do so,<br>
and many of those are active contributors to nova. We will work<br>
together.<br>
<br>
The other angle is that, actually, placement is several months ahead<br>
of nova in terms of features and it would be to everyone's advantage if<br>
placement, from a feature standpoint, took a time out (to extract)<br>
while nova had a chance to catch up with fully implementing shared<br>
providers, nested resource providers, consumer generations, resource<br>
request groups, using the reshaper properly from the virt drivers,<br>
having a fast forward upgrade script talking to PlacementDirect, and<br>
other things that I'm not remembering right now. The placement side<br>
for those things is in place. The work that it needs now is a<br>
_diversity_ of callers (not just nova) so that the features can been<br>
fully exercised and bugs and performance problems found.<br>
<br>
The projects above, which might like to--and at various times have<br>
expressed desire to do so--work on features within placement that<br>
would benefit their projects, are forced to compete with existing<br>
priorities to get blueprint attention. Though runways seemed to help<br>
a bit on that front this just-ending cycle, it's simply too dense a<br>
competitive environment for good, clean progress.<br>
<br>
4. While extracting the placement code into another repo within the<br>
compute umbrella might help a small amount with some of the<br>
competition described in item 3, it would be insufficient. The same<br>
forces would apply.<br>
<br>
Similarly, _if_ there are factors which are preventing some people<br>
from being willing to participate with a compute-associated project,<br>
a repo within compute is an insufficient break.<br>
<br>
Also, if we are going to go to the trouble of doing any kind of<br>
disrupting transition of the placement code, we may as well take as<br>
a big a step as possible in this one instance as these opportunities<br>
are rare and our capacity for change is slow. I started working on<br>
placement in early 2016, at that time we had plans to extract it to<br>
"it's own thing". We've passed the half-way point in 2018.<br>
<br>
5. In OpenStack we have a tradition of the contributors having a<br>
strong degree of self-determination. If that tradition is to be<br>
upheld, then it would make sense that the people who designed and<br>
wrote the code that is being extracted would get to choose what<br>
happens with it. As much as Mel's and Dan's (only picking on them<br>
here because they are the dissenting voices that have showed up so<br>
far) input has been extremely important and helpful in the evolution<br>
of placement, they are not those people.<br>
<br>
So my hope is that (in no particular order) Jay Pipes, Eric Fried,<br>
Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,<br>
Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to<br>
placement whom I'm forgetting [1] would express their preference on<br>
what they'd like to see happen.<br></blockquote><div><br></div><div>Sorry, I didn't read all the reply, compare to 70 replies, I prefer to review some specs...English is heavy for me.</div><div><br></div><div>I'm not very care about the extraction. But in the currently situation, I think placement contributors and nova contributors still need work to together, the resharp API is an example. So whatever we extract the placement or not, pretty sure nova and placement should work together.</div><div><br></div><div>And really hope we won't have separate room in the PTG for placement and nova..I don't want to make a hard choice to listen which one...I already used to stay at one spot in a week now.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At the same time, if people from neutron, cinder, blazar, zun,<br>
mogan, ironic, and cyborg could express their preferences, we can get<br>
through this by acclaim and get on with getting things done.<br>
<br>
Thank you.<br>
<br>
[1] My apologies if I have left you out. It's Saturday, I'm tried<br>
from trying to make this happen for so long, and I'm using various<br>
forms of git blame and git log to extract names from the git history<br>
and there's some degree of magic and guessing going on.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Chris Dent ٩◔̯◔۶ <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent tw: @anticdent</div></div><br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>