<div dir="ltr">Hi all, <div><br></div><div>We have to much different branches about scheduler (so I have to repeat here also).</div><div><br></div><div>I am against to add some extra tables that will be joined to compute_nodes table on each scheduler request (or adding large text columns).</div>
<div>Because it make our non scalable scheduler even less scalable. </div><div><br></div><div>Also if we just remove DB between scheduler and compute nodes we will get really good improvement in all aspects (performance, db load, network traffic, scalability )</div>
<div>And also it will be easily to use another resources provider (cinder, ceilometer e.g..) in Nova scheduler. </div><div><br></div><div>And one more thing this all could be really simple implement in current Nova, without big changes </div>
<div> <a href="https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit?usp=sharing</a></div>

<div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div><div>Mirantis Inc.</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 8:44 PM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>> IIUC, Ceilometer is currently a downstream consumer of data from<br>
> Nova, but no functionality in Nova is a consumer of data from<br>
> Ceilometer. This is good split from a security separation point of<br>
> view, since the security of Nova is self-contained in this<br>
> architecture.<br>
><br>
> If Nova schedular becomes dependant on data from ceilometer, then now<br>
> the security of Nova depends on the security of Ceilometer, expanding<br>
> the attack surface. This is not good architecture IMHO.<br>
<br>
</div>Agreed.<br>
<div><br>
> At the same time, I hear your concerns about the potential for<br>
> duplication of stats collection functionality between Nova &<br>
> Ceilometer. I don't think we neccessarily need to remove 100% of<br>
> duplication. IMHO probably the key thing is for the virt drivers to<br>
> expose a standard API for exporting the stats, and make sure that<br>
> both ceilometer & nova schedular use the same APIs and ideally the<br>
> same data feed, so we're not invoking the same APIs twice to get the<br>
> same data.<br>
<br>
</div>I imagine there's quite a bit that could be shared, without dependency<br>
between the two. Interfaces out of the virt drivers may be one, and the<br>
code that boils numbers into useful values, as well as perhaps the<br>
format of the JSON blobs that are getting shoved into the database.<br>
Perhaps a ceilo-core library with some very simple primitives and<br>
definitions could be carved out, which both nova and ceilometer could<br>
import for consistency, without a runtime dependency?<br>
<span><font color="#888888"><br>
--Dan<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>