<br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 2:59 AM, Jiang, Yunhong <span dir="ltr"><<a href="mailto:yunhong.jiang@intel.com" target="_blank">yunhong.jiang@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>               There are two type potential relationship between counters.<br>
> One is counters from the same pollster, another one is counters from different<br>
> pollsters. I don't think we need consider counters from notification event (am I<br>
> right?).<br>
><br>
><br>
><br>
> We will want all of the data published by ceilometer to be processed in the<br>
> same way, so the notification data will need to go through the pipelines, too.<br>
<br>
</div>I mean we don't need consider relationship from different notifications, sorry for not clear.<br></blockquote><div><br></div><div>Ah, yes, you're right. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
><br>
> Aggregation of data between counters is an implementation detail of the<br>
> transformer or publisher that needs the aggregation, so I don't think we want<br>
> to handle it by grouping data in our main loop. For one thing, we can't predict<br>
> all of the ways the different transformers will want to aggregate data (by<br>
> instance, by project, by something like the public IP address of a load balanced<br>
> service, etc.). A more general solution would be to give the pipeline a signal<br>
> that there is no more data coming -- a flush() call, or something similar -- and<br>
> let the transformer handle caching data internally until it sees the end of the<br>
> data.<br>
<br>
</div>For this NetPollster specific issue, I'd take Eglyn's suggestion to calculate it in the source pollster.<br></blockquote><div><br></div><div>That moves the information about the aggregation very far from the source that is going to consume it. It also means we have to do something similar for all of the other cases. We have the information we need to let the transformers aggregate the data, we should do it there.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div>In order to be generic, we won't want to include any extra details. Think about it like a commit() call on a database handle or flush() on a file handle. Each pipeline should be flushed after all counter data has been sent to it. We wake up on the timer event, collect the data we need for all pipelines, push the data into the pipelines, then call flush to say "no more data is coming right now." Managing any contextual information used to aggregate the data (like the instance id) is the responsibility of the transformer or publisher.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Thanks<br>
--jyh<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>