Open Stack

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: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
> __________________________________________________________________________
> 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

-- 
gord