<div dir="ltr">Hi Chris,<div><br></div><div>Thanks for the update, it's very clear about what we are going to achieve in Newton release.</div><div><br><br><div class="gmail_quote">2016-07-29 0:09 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span><br></span>So we had a discussion in Hillsboro about that with no consensus yet, if you remember.<br>I heard different opinions on how nova-scheduler would integrate with the placement API in Ocata, and I was concerned by this service doing an HTTP call to an external API. My idea was rather to integrate the new placement tables into the existing HostManager, so that instead of getting a full list of compute nodes, we would provide to the filters a list of resource providers matching the query.<br><br></div></blockquote><div><br></div><div>I agree to use HostManager to encapsulate the implementation about how scheduler build up host states (or scheduler caches). It is flexible to achieve multiple strategies, the HostManager may: 1) continue to reload the full list of host states in the existing filter scheduler; 2) reload all caches every configured seconds in caching scheduler; 3) get a partial list pre-filtered by placement engine; 4) switch to an eventually consistent solution that rarely reload caches and minimizes pressure to database. Quantitative related filters can be unconfigured if we use the 3rd HostManager.</div><div><br></div><div>-- Yingxin</div></div></div></div>