[openstack-dev] [ceilometer] Aodh has been imported, next steps
gord at live.ca
Thu Jul 2 13:54:29 UTC 2015
On 02/07/2015 4:43 AM, Ryota Mibu wrote:
> 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.
>> -----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:
>>>> 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,
>>> * 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev