[openstack-dev] Gantt (Scheduler) meeting agenda
sbauza at redhat.com
Mon Jan 19 20:21:47 UTC 2015
Le 19/01/2015 20:25, Ed Leafe a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi all,
> I want to make sure that everyone is present and prepared to discuss the
> one outstanding spec for Kilo: https://review.openstack.org/#/c/138444/
> In the words of Jay Pipes, we are at an impasse: Jay and I prefer an
> approach in which the scheduler loads up the information about the
> compute nodes when it starts up, and then relies on the compute nodes to
> update their status whenever an instance is create/destroyed/resized.
> Sylvain prefers instead to have the hosts query that information for
> every call to _get_all_host_states(), adding the instance information to
> the Host object as an InstanceList attribute. I might be a little off in
> my summary of the two positions, but they largely reflect the preference
> for solving this issue.
Sounds like there is a misunderstanding with my opinion.
That's unfortunate that even if we had a Google Hangout, we have to
discuss again what we agreed.
But OK, let's discuss again what we said and let me try to provide again
a quick explanation about my view here...
So, as I said during the Hangout, the scheduler is not having an
HostState Manager created when the scheduler service is running, but
rather created each time a query is coming in.
That means that if you want to persist an information, it needs to be
updated in the compute_nodes DB table so it would instanciate
accordingly the HostState object that filters are consuming.
I think we all agree with the fact that querying instances status should
be done by looking at HostState instead of querying DB directly, that's
a good point.
So, having said that, the discussions are about how to instantiate
HostState and deal with potential race conditions that an asynchronous
call would have.
By saying I was thinking about a call in _get_all_host_states(), I was
just saying that it was the current only way to add some details in
HostState was by doing that way.
Considering a scheduler service for persisting HostState is totally
having my +1 on it. Are we sure it should be done in that spec ? I'm not
sure at all.
> IMO, the former approach is a lot closer to the ideal end result for an
> independent scheduler service, whereas the latter is closer to the
> current design, and would be less disruptive code-wise. The former *may*
> increase the probability of race conditions in which two schedulers
> simultaneously try to consume resources on the same host, but there are
> several possible ways we can reduce that probability.
As I said, the former approach is requiring a persistent HostState
manager that we don't have now. That sounds interesting and you have my
vote, but that should not be handled in the spec you are mentioning and
requesting for a Spec Freeze exception.
Honestly, are we talking about coding stuff for Kilo ? If yes, I don't
think the former approach is doable for Kilo, in particular as no code
has been written yet.
If we're talking about what the Scheduler should look in the future,
then yes I'm 100% with you.
> So please read up on that spec, and come to the meeting tomorrow
> prepared to discuss it.
> BTW, the latter approach is very similar to an earlier version of the
> spec: https://review.openstack.org/#/c/138444/8/ . We seem to be going
> in circles!
Are you sure that the patchset you are quoting is the proposal I'm
Keep in mind I'm trying to see a common approach for the same paradigm
that has been approved here
> - --
> - -- Ed Leafe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> -----END PGP SIGNATURE-----
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev