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