Open Stack

> 	        There are two type potential relationship between counters.
> One is counters from the same pollster, another one is counters from different
> pollsters. I don't think we need consider counters from notification event (am I
> right?).
> 
> 
> 
> We will want all of the data published by ceilometer to be processed in the
> same way, so the notification data will need to go through the pipelines, too.

I mean we don't need consider relationship from different notifications, sorry for not clear.

> 
> Aggregation of data between counters is an implementation detail of the
> transformer or publisher that needs the aggregation, so I don't think we want
> to handle it by grouping data in our main loop. For one thing, we can't predict
> all of the ways the different transformers will want to aggregate data (by
> instance, by project, by something like the public IP address of a load balanced
> service, etc.). A more general solution would be to give the pipeline a signal
> that there is no more data coming -- a flush() call, or something similar -- and
> let the transformer handle caching data internally until it sees the end of the
> data.

For this NetPollster specific issue, I'd take Eglyn's suggestion to calculate it in the source pollster.

Generally, I think we can add or something like notification() or flulsh() to the pipeline interface in future. The notification can be information like instance closed with instance_id, IP address released etc. The pipeline pass such information down to the transformers. By default, the transformer will simply ignore such information. 

Thanks
--jyh