Open Stack

> >>> Probably, but the scope of ceilo has widened a bit from pure
> >>> metering.
> >>
> >> Right. From a far remove, that looks like a mistake at this early
> >> stage.
> > 
> > OK, well its a point we've gotten to after a lot of discussion
> > (at the summit and even prior to that) and the widening of scope
> > was also made clear at the TC meeting that endorsed ceilo for
> > incubation.
> 
> (With my TC hat on)
> 
> One of the positive aspects that led Ceilometer being accepted in
> Incubation is its lightweight approach to integration with other core
> projects, and how little constraints it placed on those.
> 
> Widening the Ceilometer scope to general monitoring sounded
> like a good idea, but if going this way forces us to dump its
> lightweight approach to integration and make core projects and
> release management jump through process hoops, it doesn't sound
> too much like a good idea anymore.

One bit of relevant background here ... the nova integration
approach being discussed (polling the hypervisor as opposed to
entirely relying on notifications) has been in ceilometer pretty
much from the get-go.

So it's not a totally new thing we're proposing, more a change to
make this dependency more locked-down stability-wise and hence more
manageable than before.

In my view it isn't so much the introduction of user-oriented
monitoring that's driving this, rather it's something we'd have
had to revisit anyway.

One of the arguments being made is that *if* we were to
concentrate entirely on metering, then we could feasibly change
our integration approach to nova in a different way (by dropping
polling entirely and instead relying completely on notifications).

Cheers,
Eoghan