Open Stack

> Eoghan, I think the issue for option #4 apply to #3 also, right? Even
> with option #3, a loaded nova compute service may fall behind the
> periodic task. After all, usage stats always need periodic task.

Yep, true that.

I guess I'm assuming a higher bar for timeliness when it comes to
sampling stats, than we'd accept for "existence" style notifications.

If I'm metering the existence of an instance for billing purposes,
then as long as I'm told it still exists 12 times an hour, I wouldn't
be too worried if these notifications weren't precisely spaced at
5 min intervals ... 4mins 40s followed by 5mins 20s would be OK
if the granularity for billing is only an instance-hour anyway.

Whereas for metrics that may trigger immediate operator paging and/or
autoscaling actions, I'd want to minimize jitter around the sampling
points as much as possible.

> So I'm to #4, and with followed changes:

OK, interesting.

> a) nova, cinder or other project publish the raw data through
> ceilometer's rpc call (in fact, through configuration, it can be any
> rpc call provided by metering components). Of course, the raw data
> format should be well defined and documented.

So I was hoping to avoid the message bus *needing* to be involved
here.

Say for example a particular measurement was to be pushed to the
CW metric store, but wasn't of interest for metering. In that case
I'd like to kick it straight over to the CW PutMetricData API,
instead of putting through one hop of the message bus first.

> b) ceilometer do the translation from raw data to metering
> information.

Yep, makes sense.
 
> c) Ceilometer use nova API to configure nova's publish attribute,
> like what resources should be published, the frequency of the
> publish etc.

Yeah, so that's the kind of leakage I was a bit worried about (it's
likely to be a bit more complicated than just registering a single
frequency, as different meter/publisher pairs will have varying
periods that make sense).

Cheers,
Eoghan