On 02/07/2015 4:43 AM, Ryota Mibu wrote:
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?
this sounds like a good idea, we should probably adopt something similar
to the graduation process for oslo libs. at quick glance, the code is
all structured the same -- under different main folder -- so i believe
it should be a easy port if coding against current ceilometer repo to
move it under aodh afterwards.
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
--
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
