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

Dan Smith dms at danplanet.com
Mon Aug 20 14:08:55 UTC 2018


>> 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



More information about the OpenStack-dev mailing list