Open Stack

On Tue, Dec 10, 2013 at 11:48 PM, Gary Kotton <gkotton at vmware.com> wrote:

>
>
> On 12/11/13 12:43 AM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:
>
> >
> >
> >On Tuesday, December 10, 2013 4:17:45 PM, Maithem Munshed 71510 wrote:
> >> Hello,
> >>
> >> I was wondering, what is the reason behind having nova audit resources
> >> as opposed to using usage stats directly from what is reported by the
> >> compute driver. The available resources reported from the audit can be
> >> incorrect in some cases. Also, in many cases the reported usage stats
> >> from the driver are correct, so auditing periodically while having the
> >> usage stats from the driver is inefficient. One of the which result in
> >> an incorrect audit is: existing VMs on a hypervisor that are created
> >> prior to deploying nova. As a result, the scheduler will see more
> >> available resources than what actually is available. I am aware that
> >> Nova shouldn¹t be managing VMs that it hasn¹t created, but the
> >> reported available resources should be as accurate as possible.
>


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.


> >>
> >> I have proposed the following blueprint to provide the option of using
> >> usage stats directly from the driver :
> >>
> >>
> >>
> https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.n
> >>et/nova/%2Bspec/use-driver-usage-stats&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0
> >>A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8NY7Hm
> >>djKaREzjyWdCIsrjbjolGum3k878%3D%0A&s=c7dfed6064da0be905447da3533cf6b6d2fa
> >>7eefb2364fad1df4d484e39a9914
> >>
> >> I would like to know what your thoughts are and would appreciate
> >>feedback.
> >>
> >> Regards,
> >>
> >> Maithem
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >>
> >>
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
> >>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
> >>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8NY7HmdjK
> >>aREzjyWdCIsrjbjolGum3k878%3D%0A&s=d8f5240e69583b063b2435d4e62244f1df9acaa
> >>268d332922afba4d35a0add57
> >
> >One (big) problem is the virt drivers don't follow a standard format
> >for the usage diagnostics, which has been discussed before in the
> >mailing list [1].
> >
> >There is a nova blueprint [2] for standard auditing formats like in
> >ceilometer which might be related to what you're looking for.
>
> This is one of the issue that we spoke about at the summit. At the moment
> the virt drivers return their usage statistics (not VM diagnostics). The
> resource tracker just ignores this, well actually it has a LOG debug for
> the results
> (
> https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke
> r.py#L401), and proceed to calculate the available resources on the
> compute node.
>
> The conclusion from that session was that we should add in a configuration
> variable (to ensure backward compatibility) which will enable the resource
> tracker to make use of the girt driver statistics instead of recalculating
> them
> (
> https://github.com/openstack/nova/blob/master/nova/compute/resource_tracke
> r.py#L291)
>
>
+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.


> Thanks
> Gary
>
> >
> >[1]
> >
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/pipe
> >rmail/openstack-dev/2013-October/016385.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D
> >%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8N
> >Y7HmdjKaREzjyWdCIsrjbjolGum3k878%3D%0A&s=df8314a31fb99b591d081b1888f38e2be
> >9e19f289afaaa7224844a964d4b1680
> >[2]
> >
> https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne
> >t/nova/%2Bspec/support-standard-audit-formats&k=oIvRg1%2BdGAgOoM1BIlLLqw%3
> >D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8
> >NY7HmdjKaREzjyWdCIsrjbjolGum3k878%3D%0A&s=f8f7b3aebf0e3226926146aed4b6caf4
> >d380d410f35fb7ee974655ad6190fa71
> >
> >--
> >
> >Thanks,
> >
> >Matt Riedemann
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
> >bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
> >H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=x02rSPjpn8NY7HmdjKaRE
> >zjyWdCIsrjbjolGum3k878%3D%0A&s=d8f5240e69583b063b2435d4e62244f1df9acaa268d
> >332922afba4d35a0add57
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/ef119ae1/attachment.html>