[openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)
mriedemos at gmail.com
Fri May 19 13:48:02 UTC 2017
On 5/19/2017 8:14 AM, Chris Dent wrote:
> On Thu, 18 May 2017, Matt Riedemann wrote:
>> We didn't really get into this during the forum session, but there are
>> different opinions within the nova dev team on how to do claims in the
>> controller services (conductor vs scheduler). Sylvain Bauza has a
>> series which uses the conductor service, and Ed Leafe has a series
>> using the scheduler. More on that in the mailing list .
> Since we've got multiple threads going on this topic, I put some
> of my concerns in a comment on one of Ed's reviews:
> It's a bit left fieldy but tries to ask about some of the long term
> concerns we may need to be thinking about here, with regard to other
> services using placement and maybe them needing a
> scheduler-like-thing too (because placement cannot do everything).
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Thanks for pointing this out Chris. I still need to read Ed's blog post
(separate thread), but we've said for a few releases now that the
long-term goal is to split placement out of nova, and leave
nova-scheduler within nova, since the scheduler code is very
nova-specific (think of all the affinity sync stuff).
I appreciate thinking big and long-term, but I really don't want to
spend a lot of time right now questioning every move we make and whether
that might hurt the ability to split the scheduler code out in 5 years
because some other project wants to use it - which is Gantt 2.0 and I
haven't heard any other project express an interest in something like that.
I don't know how other projects do claims today, and how different they
are from how nova does them. So there would seem to be a lot of
discovery involved before we could even go down that path, not to
mention all of the nova-specific code that would need to come out of the
scheduler, or be made generic/pluggable.
Again, I think if we spend too much time thinking about that we're not
going to get anything done in Pike.
More information about the OpenStack-dev