openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Wed, Nov 7, 2012 at 10:21 PM, Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>wrote:

> Hey!
>
> (sorry for the top-posting, crappy web client)
>
> There is a periodic task already in the compute manager that can handle
> this:
> https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3021
>
> 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.
>
> 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.
>
>
> https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L152
>
> https://github.com/openstack/nova/blob/master/nova/virt/xenapi/driver.py#L392
>
> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2209
>
> 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).
>

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?

Doug


>
> 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.
>
> 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.
>
> Hope I answered your question? If not, just repeat it in another way and
> I'll try again :)
>
> -S
>
>
>
> ________________________________________
> From: openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx[openstack-bounces+sandy.walsh=
> rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of Eoghan Glynn [
> eglynn@xxxxxxxxxx]
> Sent: Wednesday, November 07, 2012 4:32 PM
> To: OpenStack Development Mailing List
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] [openstack-dev] [metering][ceilometer] Unified
> Instrumentation, Metering, Monitoring ...
>
> > Here's a first pass at a proposal for unifying StackTach/Ceilometer
> > and other instrumentation/metering/monitoring efforts.
> >
> > It's v1, so bend, spindle, mutilate as needed ... but send feedback!
> >
> > http://wiki.openstack.org/UnifiedInstrumentationMetering
>
> Thanks for putting this together Sandy,
>
> We were debating on IRC (#heat) earlier the merits of moving the
> ceilometer "emission" logic into the services, e.g. directly into the
> nova-compute node. At first sight, this seemed to be what you were
> getting at with the suggestion:
>
>  "Remove the Compute service that Ceilometer uses and integrate the
>   existing fanout compute notifications into the data collected by the
>   workers. There's no need for yet-another-worker."
>
> While this could be feasible for measurements driven directly by
> notifications, I'm struggling with the idea of moving say the libvirt
> polling out of the ceilometer compute agent, as this seems to leak too
> many monitoring-related concerns directly into nova (cadence of polling,
> semantics of libvirt stats reported etc.).
>
> So I just wanted to clarify whether the type of low level unification
> you're proposing includes both push & pull (i.e. notification & polling)
> or whether you mainly had just former in mind when it comes to ceilometer.
>
> Cheers,
> Eoghan
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>