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:g...@live.ca] > Sent: Tuesday, June 30, 2015 3:48 AM > To: openstack-dev@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev