Open Stack

On 15/11/12 02:45 -0500, Eoghan Glynn wrote:
>
>> > Its more that nova would have to start becoming concerned with the
>> > semantics of stats that ceilometer currently interprets. For
>> > example,
>> > nova might need to know how to derive say CPU utilization from the
>> > cumulative CPU time samples reported by the hypervisor driver.
>> >
>> > So, its not knowledge of the ceilo queues leaking into nova that
>> > I'd be concerned about, more leakage of ceilo logic.
>>
>> Why does nova have to do that logic?  That can't be done on the
>> notification consumption side?  If it can't be done on the
>> consumption side, then I think it seems fair to put it in nova.
>
>Yeah, the derived metric was probably a bad example, if the time
>samples were actually timestamped on the nova side (e.g. at the
>time of reading from libvirt as opposed to a random number of
>millis later when the notification is sent) then the derivation
>could indeed be done on the consumer side.
>
>A better example would be the reporting cadence - nova would need
>to know for example that something in the ceilo world was interested
>in seeing CPU time every 60s, but only cared about instance existence
>notifications every 300s.
>
>> What are the performance differences with this approach vs options 1
>> and 2?  If performance is a major concern, then an event based approach
>> seems like it could be more efficient.  Or is there a reason a poll
>> approach is needed?
>
>Its not so much performance as timeliness - can we be sure that a
>measure we need at 60s granularity will actually be taken every minute
>on the dot, or with everything else going on within the nova-compute
>service might we end up with lots of random jitter on the measurement
>points.

I still like option 4, but keep it a separate daemon (like it is in ceilometer)
to guarantee the timeliness.

As far as "leakage" goes, we have heaps of nova "leakage" in ceilometer,
I think we will have a lot less ceilometer in nova with this setup
especially if there is some kind of common library that we can provide.

-Angus

>
>Cheers,
>Eoghan
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev