Open Stack

On Wed, Nov 28, 2012 at 12:12:05PM +0100, Julien Danjou wrote:
> On Wed, Nov 28 2012, Eoghan Glynn wrote:
> 
> A quick answer, I think Eoghan wrote what I would have written if I had
> been faster to reply. :)
> 
> >> 	Also I envision the CW data will be stored in the storage, with a
> >> 	dimensions table, and CW data in another table. Each
> >> 	(metricname+dimensions) combination will have an entry on the
> >> 	dimension table. A table for the alarm, and alarm table will be
> >> 	updated when new data added.
> >
> > Yes, I would expect that it would involve some different data structures in
> > the store.
> >
> > In fact it could well be a completely different store (e.g. a metric store
> > based on Cassandra, while the metering store defaults to Mongo).
> 
> Yes, the point is that this is not really a Ceilometer concern as Eoghan
> says. The CW publisher pushes in another software, that's it. :)
> 
> >> 	With this envision, the translation from Counter to CW data will
> >> 	happen in publisher
> >
> > In the transformer, not the publisher, I would have thought.
> 
> Yes, in the transformers (plural probably).
> 
> >>       and we may need various type of transformer to
> >> 	achieve it, including a) Unit translation like from kb to byte, b)
> >> 	interval translation like from 10s to 60s,
> >
> > I don't think we need interval translation. The metric is just pushed to
> > CW when it becomes available. The push doesn't involve specifying a period.
> > Instead the period (e.g. 60s) is specified when the metric is queried. If
> > the polling interval was set to 10s, then a GetMetricStatistics call with
> > period=60s would result in aggregation over the ~6 datapoints per period.
> 
> Yeah, not sure interval translation is the role of any transformer
> indeed. It's more the "scheduler" job to honor publisher requirements
> about events interval they want.
> 
> >> 	However, if we will achieve CW data from API side (that also make
> >> 	sense and seems more flexible), then I don't think any transformer
> >> 	needed, except the CPU utilization, which has been implemented
> >> 	already. The interval in fact does not matter in such situation,
> >> 	except the interval of the pollster.
> >
> > Well it depends on whether the CW service in integral to ceilo, or at
> > arms length. In the latter case, e.g. Synaps, the CW publisher would do
> > the metric push via the CW public API.
> 
> Yep, for now we don't envisage doing CW inside Ceilo. If Ceilometer API
> can do that at some point for an almost free cost, we'll see. For now
> it's not in our scope.

So are you saying you won't support adding a CW compatible API, or that you
won't support the concept (or at least requirements) of CW at all inside
ceilometer?

This has a pretty big impact in terms of the heat potential usage of
ceilometer as a metric source - I'd hoped we could move away from storing
metric data at all inside heat, instead using metrics and associated
statistics from ceilometer.

It seems like you're saying you'll only support a hook to push metric data
to an external CW API (which has it's own datastore), so heat will need to
either maintain it's own CW API implementation and datastore or move to
using something like Synaps (*and* ceilometer) to provide CW style metrics?

Clarification appreciated, as this seems like a change in direction from (my
understanding of) previous goals.

--
Steve Hardy
Red Hat Engineering, Cloud