Open Stack

Hi,


I'd like to see how we can develop new alarm features, since I'm working on event-alarm.

Having duplicated code bases may confuse developer too, so we should have some policies like:

 * aodh focus on making sure that it provides existing API and functionality as of kilo to end users
 * ceilometer/alarm is open to develop new experimental features until L2/L3
 * having a merge window to move those new features to aodh from ceilometer/alarm around L3

What do you think?


Thanks,
Ryota

> -----Original Message-----
> From: gordon chung [mailto:gord at live.ca]
> Sent: Tuesday, June 30, 2015 3:48 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
> 
> 
> 
> On 29/06/2015 11:40 AM, Chris Dent wrote:
> > On Mon, 29 Jun 2015, Julien Danjou wrote:
> >
> >> Hi team,
> >>
> >> Aodh has been imported and is now available at:
> >>
> >>  https://git.openstack.org/cgit/openstack/aodh/
> >
> > woot!
> >
> >> I'm pretty clear about the next steps for Aodh and what we need to
> >> build, but something is still not clear to me. Do we go ahead and
> >> bite the bullet and remove ceilometer-alarming from ceilometer in Liberty?
> 
> i think we should follow up with the packagers. if i understand correctly, the location of the code is not known from
> a user pov, it's the packagers that build the appropriate packages for them to use.
> 
> if from packagers pov, they just need to work against Aodh, then i would lean more to removing alarming from Ceilometer
> repo asap to avoid maintaining duplicate code bases and the eventual diversion of the two.
> 
> >
> > This is the big question and is one of the things listed on the
> > potential agenda for the mid-cylce. When we do the splits do we
> > deprecate or delete the old code. Given the high chance of us
> > missing some of potential issues it seems like hasing it some before
> > the mid-cylce is a good idea.
> >
> > The two big overarching issues (that inform a lot of the details)
> > that I'm aware of are:
> >
> > * If we delete then we need to make sure we're working hand in hand
> >   with all of: downstream packagers, tempest, grenade, devstack,
> >   etc.
> >
> > * If we deprecate will people bother to use the new stuff?
> 
> i would think/hope the experience from end user doesn't actually change.
> ie. all the same packaged services remain.
> 
> >
> > I'm sure there are plenty of others.
> >
> 
> --
> 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