<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>As far as I understand we have a base agreement that both specs are appropriate and either of that two features are shifted to Mitaka cycle.<br><br></div>Gordon probably that question to you:<br></div>Are we going to create a new folder in spec's dir for next cycle, or we continue discussing "new" specs as part of liberty?<br></div>And the second one: are we going to create special rep for AODH specs or ceilometer-specs is ok for all new projects?<br><br></div>Thank you in advance,<br><div class="gmail_extra"><div><div class="gmail_signature">Igor Degtiarov<br>Software Engineer<br>Mirantis Inc.<br><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div>
<br><div class="gmail_quote">On Fri, Aug 7, 2015 at 10:59 AM, Ryota Mibu <span dir="ltr"><<a href="mailto:r-mibu@cq.jp.nec.com" target="_blank">r-mibu@cq.jp.nec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
<br>
Sorry for my late response and my absent in weekly meetings...<br>
<br>
I'm not sure whether I captured your idea correctly, but I prefer the second approach now.<br>
<br>
I agreed the point Igor and liusheng mentioned that the second approach enables end users to have configurable expire-time.<br>
<br>
In another point of view, the first approach may affect pipeline performance since it have to keep event sequence state or have to access DB for state querying when each event received. This is just my concern, but I think event pipeline should be simplest and limited to have only common features between event data storage, event alarming and other receiver like audit system.<br>
<br>
<br>
Thanks,<br>
Ryota<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: liusheng [mailto:<a href="mailto:liusheng1175@126.com">liusheng1175@126.com</a>]<br>
> Sent: Wednesday, August 05, 2015 1:12 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms<br>
><br>
> Hi,<br>
><br>
> Maybe the event transformer is needed in some use cases to generate new events or do transformations like the samples<br>
> handling. but for this timeout event alarming requirement, the 'timeout' of alarms will be various, it not a good idea<br>
> of changing event_pipeline.yaml to generate new events based on events timeout when we need an event-timeout alarm. and<br>
> also, the access of event pipeline definitions to users is inadvisable. I personally think it'd better to implement the<br>
> second option and based on Ryota's proposal.<br>
><br>
> Best Regards<br>
> Liusheng<br>
><br>
><br>
> 在 2015/8/5 3:36, gord chung 写道:<br>
><br>
><br>
> hi Igor,<br>
><br>
> i would suggest you go with second option as i believe your implementation will overlap and reuse some of the<br>
> functionality Ryota would code for his alarm spec [1]. also, since Aodh is working on an independent release cycle, it'll<br>
> give you some more time as i don't think we'd be able to get this into Liberty if we went the pipeline route.<br>
><br>
> [1] <a href="http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html</a><br>
><br>
><br>
> On 04/08/2015 10:00 AM, Igor Degtiarov wrote:<br>
><br>
><br>
> Hi folks,<br>
><br>
><br>
> On our meatup we agreed to add timeout event alarms [1](Event-Base Alarming part).<br>
> In ToDo task "Сhoose the optimal way for timeout alerting implementation"<br>
><br>
> Now we have two proposition for implementation:<br>
><br>
> - first is to add timeout param in event pipeline (transformer part) [2]<br>
> -- weakness of this approach is that we cannot allow user change config files, so only administrator<br>
> will be able to set rules for timeout events alarms, and that is not what we are expecting from alarms.<br>
><br>
> - second is additional optional parameters in event alarms description like sequence of required events<br>
> and timeout threshold. Event alarm evaluator looks thru getting events and evaluates alarm if even one event from required<br>
> sequence isn't received in set "timeout".[3]<br>
><br>
><br>
> It seems that second approach is better it doesn't have restrictions for end user.<br>
><br>
> Hope for your help in choosing optimal way for implementation.<br>
> (In specs review there is silence now)<br>
><br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle</a><br>
> [2] <a href="https://review.openstack.org/#/c/162167" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/162167</a><br>
> [3] <a href="https://review.openstack.org/#/c/199005" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/199005</a><br>
><br>
><br>
> Igor Degtiarov<br>
> Software Engineer<br>
> Mirantis Inc.<br>
> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> --<br>
> --<br>
> gord<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>