<br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 10:21 PM, Sandy Walsh <span dir="ltr"><<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey!<br>
<br>
(sorry for the top-posting, crappy web client)<br>
<br>
There is a periodic task already in the compute manager that can handle this:<br>
<a href="https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3021" target="_blank">https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3021</a><br>
<br>
There seems to be some recent (to me) changes in the manager now wrt the resource_tracker.py and stats.py files about how this information gets relayed. Now it seems it only goes to the db, but previously it was sent to a fanout queue that the schedulers could use.<br>
<br>
Regardless, this is done at a high enough level that it doesn't really care about the underlying virt layer, so long at the virt layer supports the get_available_resource() method.<br>
<br>
<a href="https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L152" target="_blank">https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L152</a><br>
<a href="https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L392" target="_blank">https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L392</a><br>
<a href="https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2209" target="_blank">https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2209</a><br>
<br>
I'd add a hook in there do what we want with this data. Write it to the db, send it over the wire, whatever. If there is additional information required, it should go in this dictionary (or we should define a format for extensions to it).<br>
</blockquote><div><br></div><div>It looks like that is collecting resource data, but not usage data. For example, there's no disk I/O information, just disk space. Is that what you mean by adding extra information to the dictionary?</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The --periodic_interval value is meant to be the "fastest tick" approach and the individual methods have to deal with how many multiples of the base tick it should use. So you can have different data reported at different intervals.<br>
<br>
Now, the question of polling vs. pushing shouldn't really matter if the sampling rate is predetermined. We can push when the sample is taken or we can read from some other store from an external process ... but the sampling should only be done in one place, once.<br>
<br>
Hope I answered your question? If not, just repeat it in another way and I'll try again :)<br>
<br>
-S<br>
<br>
<br>
<br>
________________________________________<br>
From: openstack-bounces+sandy.walsh=<a href="mailto:rackspace.com@lists.launchpad.net">rackspace.com@lists.launchpad.net</a> [openstack-bounces+sandy.walsh=<a href="mailto:rackspace.com@lists.launchpad.net">rackspace.com@lists.launchpad.net</a>] on behalf of Eoghan Glynn [<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>]<br>
Sent: Wednesday, November 07, 2012 4:32 PM<br>
To: OpenStack Development Mailing List<br>
Cc: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
<div class="im HOEnZb">Subject: Re: [Openstack] [openstack-dev] [metering][ceilometer] Unified Instrumentation, Metering, Monitoring ...<br>
<br>
</div><div class="HOEnZb"><div class="h5">> Here's a first pass at a proposal for unifying StackTach/Ceilometer<br>
> and other instrumentation/metering/monitoring efforts.<br>
><br>
> It's v1, so bend, spindle, mutilate as needed ... but send feedback!<br>
><br>
> <a href="http://wiki.openstack.org/UnifiedInstrumentationMetering" target="_blank">http://wiki.openstack.org/UnifiedInstrumentationMetering</a><br>
<br>
Thanks for putting this together Sandy,<br>
<br>
We were debating on IRC (#heat) earlier the merits of moving the<br>
ceilometer "emission" logic into the services, e.g. directly into the<br>
nova-compute node. At first sight, this seemed to be what you were<br>
getting at with the suggestion:<br>
<br>
"Remove the Compute service that Ceilometer uses and integrate the<br>
existing fanout compute notifications into the data collected by the<br>
workers. There's no need for yet-another-worker."<br>
<br>
While this could be feasible for measurements driven directly by<br>
notifications, I'm struggling with the idea of moving say the libvirt<br>
polling out of the ceilometer compute agent, as this seems to leak too<br>
many monitoring-related concerns directly into nova (cadence of polling,<br>
semantics of libvirt stats reported etc.).<br>
<br>
So I just wanted to clarify whether the type of low level unification<br>
you're proposing includes both push & pull (i.e. notification & polling)<br>
or whether you mainly had just former in mind when it comes to ceilometer.<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>