<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 10, 2013 at 11:48 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 12/11/13 12:43 AM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
<br>
><br>
><br>
>On Tuesday, December 10, 2013 4:17:45 PM, Maithem Munshed 71510 wrote:<br>
>> Hello,<br>
>><br>
>> I was wondering, what is the reason behind having nova audit resources<br>
>> as opposed to using usage stats directly from what is reported by the<br>
>> compute driver. The available resources reported from the audit can be<br>
>> incorrect in some cases. Also, in many cases the reported usage stats<br>
>> from the driver are correct, so auditing periodically while having the<br>
>> usage stats from the driver is inefficient. One of the which result in<br>
>> an incorrect audit is: existing VMs on a hypervisor that are created<br>
>> prior to deploying nova. As a result, the scheduler will see more<br>
>> available resources than what actually is available. I am aware that<br>
>> Nova shouldnąt be managing VMs that it hasnąt created, but the<br>
>> reported available resources should be as accurate as possible.<br></div></blockquote><div><br></div><div> </div><div>While I agree there are valid use cases for wanting this. I don't think existing VMs on a hypervisor is one of them. Nova wasn't designed to share a nova-compute node, and I don't think we want make it do that either. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>><br>
>> I have proposed the following blueprint to provide the option of using<br>
>> usage stats directly from the driver :<br>
>><br>
>><br>
</div>>><a href="https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n" target="_blank">https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n</a><br>
>>et/nova/%2Bspec/use-driver-usage-stats&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0<br>
>>A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8NY7Hm<br>
>>djKaREzjyWdCIsrjbjolGum3k878%3D%0A&s=c7dfed6064da0be905447da3533cf6b6d2fa<br>
>>7eefb2364fad1df4d484e39a9914<br>
<div class="im">>><br>
>> I would like to know what your thoughts are and would appreciate<br>
>>feedback.<br>
>><br>
>> Regards,<br>
>><br>
>> Maithem<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><br>
</div>>><a href="https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi" target="_blank">https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi</a><br>
>>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r<br>
>>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8NY7HmdjK<br>
>>aREzjyWdCIsrjbjolGum3k878%3D%0A&s=d8f5240e69583b063b2435d4e62244f1df9acaa<br>
>>268d332922afba4d35a0add57<br>
<div class="im">><br>
>One (big) problem is the virt drivers don't follow a standard format<br>
>for the usage diagnostics, which has been discussed before in the<br>
>mailing list [1].<br>
><br>
>There is a nova blueprint [2] for standard auditing formats like in<br>
>ceilometer which might be related to what you're looking for.<br>
<br>
</div>This is one of the issue that we spoke about at the summit. At the moment<br>
the virt drivers return their usage statistics (not VM diagnostics). The<br>
resource tracker just ignores this, well actually it has a LOG debug for<br>
the results<br>
(<a href="https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke
r.py#L401" target="_blank">https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke<br>
r.py#L401</a>), and proceed to calculate the available resources on the<br>
compute node.<br>
<br>
The conclusion from that session was that we should add in a configuration<br>
variable (to ensure backward compatibility) which will enable the resource<br>
tracker to make use of the girt driver statistics instead of recalculating<br>
them<br>
(<a href="https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke
r.py#L291" target="_blank">https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke<br>
r.py#L291</a>)<br>
<br></blockquote><div><br></div><div>+1, one of the concerns (something which a configuration option addresses), is by using the virt driver statistics in scheduling it makes scheduling much harder to reproduce and debug. In part because not all virt drivers will report back a VM is consuming the entire RAM allocated to it, in which case a compute node can mistakenly be oversubscribed.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks<br>
Gary<br>
<br>
><br>
>[1]<br>
><a href="https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pipe" target="_blank">https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pipe</a><br>
>rmail/openstack-dev/2013-October/016385.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D<br>
>%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8N<br>
>Y7HmdjKaREzjyWdCIsrjbjolGum3k878%3D%0A&s=df8314a31fb99b591d081b1888f38e2be<br>
>9e19f289afaaa7224844a964d4b1680<br>
>[2]<br>
><a href="https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne" target="_blank">https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne</a><br>
>t/nova/%2Bspec/support-standard-audit-formats&k=oIvRg1%2BdGAgOoM1BIlLLqw%3<br>
>D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8<br>
>NY7HmdjKaREzjyWdCIsrjbjolGum3k878%3D%0A&s=f8f7b3aebf0e3226926146aed4b6caf4<br>
>d380d410f35fb7ee974655ad6190fa71<br>
<div class="im">><br>
>--<br>
><br>
>Thanks,<br>
><br>
>Matt Riedemann<br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>><a href="https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-" target="_blank">https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-</a><br>
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e<br>
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8NY7HmdjKaRE<br>
>zjyWdCIsrjbjolGum3k878%3D%0A&s=d8f5240e69583b063b2435d4e62244f1df9acaa268d<br>
>332922afba4d35a0add57<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>