Open Stack

> > > To me, the pollster or notifications handler should be
> > > responsible to emit the maximum amount of "counters" it can
> > > from what it gets. And for each counter, you would pass it
> > > through a transformer, mangling the value to some over thing.
> >
> > Isn't the Counter just a tuple of name-value pairs?
> >
> > I'm not sure how it would help to have the raw data passed via
> > a tuple as compared to kwargs?
> 
> The Counter is implemented as a namedtuple because that was enough
> for what we were doing before but gave us the ability to switch to a
> more flexible class later when our requirements changed (like now,
> where I envision more complex documentation requirements).

A-ha, got it (I was assuming the prior discussion was based on
the *existing* definition of Counter, as opposed to a new more
self-describing thing).


[...]
> > > So it's kind of generic and you can even use it to do some other
> > > stuff.
> > >
> > > Does that make sense?
> >
> > Interesting thought. I think the generic renaming approach
> > could work for the simplest cases, but say the CW transformer
> > also had to construct a few different dimensions for the
> > metric?
> >
> > For example for an instance metric, it would set the ImageId
> > dimension to the image UUID, the InstanceId dimension to the
> > instance UUID, the AutoScalingGroupName dimension to some
> > other value taken from the instance metadata.
> >
> > In that case, the logic in the CW transformer would probably have to
> > be hand-crafted instead of being generic. 
> 
> We can provide a library of generic functions for building
> transformers so everyone doesn't have to do it from scratch. I don't
> think we want deployers to have to understand or deal with all of
> that, though.

Makes sense.

Cheers,
Eoghan