Open Stack

Hi,

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.

Gordon probably that question to you:
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?
And the second one: are we going to create special rep for AODH specs or
ceilometer-specs is ok for all new projects?

Thank you in advance,
Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Fri, Aug 7, 2015 at 10:59 AM, Ryota Mibu <r-mibu at cq.jp.nec.com> wrote:

> Hi,
>
>
> Sorry for my late response and my absent in weekly meetings...
>
> I'm not sure whether I captured your idea correctly, but I prefer the
> second approach now.
>
> I agreed the point Igor and liusheng mentioned that the second approach
> enables end users to have configurable expire-time.
>
> 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.
>
>
> Thanks,
> Ryota
>
> > -----Original Message-----
> > From: liusheng [mailto:liusheng1175 at 126.com]
> > Sent: Wednesday, August 05, 2015 1:12 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
> >
> > Hi,
> >
> > Maybe the event transformer is needed in some use cases to generate new
> events or do transformations like the samples
> > handling.  but for this timeout event alarming requirement,  the
> 'timeout' of alarms will be various, it not a good idea
> > of changing event_pipeline.yaml to generate new events based on events
> timeout when we need an event-timeout alarm. and
> > also, the access of event pipeline definitions to users is inadvisable.
> I personally think it'd better to implement the
> > second option and based on Ryota's proposal.
> >
> > Best Regards
> > Liusheng
> >
> >
> > 在 2015/8/5 3:36, gord chung 写道:
> >
> >
> >       hi Igor,
> >
> >       i would suggest you go with second option as i believe your
> implementation will overlap and reuse some of the
> > functionality Ryota would code for his alarm spec [1]. also, since Aodh
> is working on an independent release cycle, it'll
> > 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.
> >
> >       [1]
> http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
> >
> >
> >       On 04/08/2015 10:00 AM, Igor Degtiarov wrote:
> >
> >
> >               Hi folks,
> >
> >
> >               On our meatup we agreed to add timeout event alarms
> [1](Event-Base Alarming part).
> >               In ToDo task "Сhoose the optimal way for timeout alerting
> implementation"
> >
> >               Now we have two proposition for implementation:
> >
> >                - first is to add timeout param in event pipeline
> (transformer part) [2]
> >                  -- weakness of this approach is that we cannot allow
> user change config files, so only administrator
> > will be able to set rules for timeout events alarms, and that is not
> what we are expecting from alarms.
> >
> >                - second is additional optional parameters in event
> alarms description like sequence of required events
> > and timeout threshold. Event alarm evaluator looks thru getting events
> and evaluates alarm if even one event from required
> > sequence isn't received in set "timeout".[3]
> >
> >
> >               It seems that second approach is better it doesn't have
> restrictions for end user.
> >
> >               Hope for your help in choosing optimal way for
> implementation.
> >               (In specs review there is silence now)
> >
> >
> >               [1]
> https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
> >               [2] https://review.openstack.org/#/c/162167
> >               [3] https://review.openstack.org/#/c/199005
> >
> >
> >               Igor Degtiarov
> >               Software Engineer
> >               Mirantis Inc.
> >               www.mirantis.com
> >
> >
> >
> >
>  __________________________________________________________________________
> >               OpenStack Development Mailing List (not for usage
> questions)
> >               Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >       --
> >       --
> >       gord
> >
> >
> >
> >
>  __________________________________________________________________________
> >       OpenStack Development Mailing List (not for usage questions)
> >       Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150817/ac7806de/attachment.html>