>> 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.
I apparently don't qualify for a vote, so I'll just reply to Jay's comments here. > I am not opposed to extracting the placement service into its own > repo. I also do not view it as a priority that should take precedence > over the completion of other items, including the reshaper effort and > the integration of placement calls into Nova (nested providers, > sharing providers, etc). > > The remaining items are Nova-centric. We need Nova-focused > contributors to make placement more useful to Nova, and I fail to see > how extracting the placement service will meet that goal. In fact, one > might argue, as Melanie implies, that extracting placement outside of > the Compute project would increase the velocity of the placement > project *at the expense of* getting things done in the Nova project. Yep, this. I know it's a Nova-centric view, but unlike any other project, we have taken the risk of putting placement in our critical path. That has yielded several fire drills right before releases, as well as complicated backports to fix things that we have broken in the process, etc. We've got a list of things that are half-finished or promised-but-not-started, and those are my priority over most everything else. > We've shown we can get many things done in placement. We've shown we > can evolve the API fairly quickly. The velocity of the placement > project isn't the problem. The problem is the lag between features > being written into placement (sometimes too hastily IMHO) and actually > *using* those features in Nova. Right, and the reshaper effort is a really good example of what I'm concerned about. Nova has been getting ready for NRPs for several cycles now, and just before crunch time in Rocky, we realize there's a huge missing piece of the puzzle on the placement side. That's not the first time that has happened and I'm sure it won't be the last. > As for the argument about other projects being able (or being more > willing to) use placement, I think that's not actually true. The > projects that might want to ditch their own custom resource tracking > and management code (Cyborg, Neutron, Cinder, Ironic) have either > already done so or would require minimal changes to do that. There are > no projects other than Ironic that I'm aware of that are interested in > using the allocation candidates functionality (and the allocation > claim process that entails) for the rough scheduling functionality > that provides. I'm not sure placement being extracted would change > that. My point about this is that "reporting" and "consuming" placement are different things. Neutron reports, we'd like Cinder to report. Ironic reports, but indirectly. Cyborg would report. Those reporting activities are to help projects that "consume" placement make better decisions, but I think it's entirely likely that Nova will be the only one that ever does that. --Dan __________________________________________________________________________ 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
