[openstack-dev] [ceilometer] Aodh has been imported, next steps
r-mibu at cq.jp.nec.com
Thu Jul 2 08:43:41 UTC 2015
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?
> -----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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev