Open Stack

On 07/08/2015 3:49 AM, Chris Dent wrote:
>
> Despite our conversation in the meeting yesterday[1] I still remain a
> bit confused about the upgrade path from alarming-in-ceilometer to
> alarming provided by aodh and the availability of the older code in
> released liberty.
>
> Much of my confusion can probably be resolved by knowing the answer to
> this question:
>
> If someone installs aodh on a machine that already has ceilometer on it
> and turns off ceilometer-alarm-notifier and ceilometer-alarm-evaluator
> (in favor of aodh-notifier and aodh-evaluator) will they be able to run
> those aodh services against their existing ceilometer.conf files[2]?
>
> What if they were, in ceilometer, using specific config for their
> alarming database (alarm_connection). Can aodh "see" and use this
> config option?
>
> Or will they need to copy and modify the existing conf files to allow
> them to carry on using their existing database config?
>
> I know that I can go try some of this in a devstack, but that's not
> really the point of the question. The point is: What are we expecting
> existing deployments to do?
>
> I had assumed that the reason for keeping alarming in ceilometer for
> the liberty release was to allow a deployment to upgrade to Liberty
> across the project suites without having to go through modifying
> alarming config and managing an alarming migration in the same step.
> That migration ought to be pretty minor (tweak a config here and
> there) but unless the answer to my first question is "yes" it has some
> significance.

following up, after speaking with Chris, a critical question was not 
just what happens to those who upgrade but what happens to those who 
choose NOT to upgrade to Aodh. to clarify, it is Ceilometer's intent to 
have Aodh as the source of alarming functionality going forward -- no 
new features have been added or will be added to the existing alarming 
code in Ceilometer. also, any new feature must be added to Aodh.

with that said, for those who choose not to upgrade and are content with 
existing alarming code, the code will exist as is for Liberty. after 
speaking with the Nova team, there has been a deprecation period between 
Cinder/Glance split before it was fully removed from packaging/code. 
Ceilometer will follow the same but will target a more aggressive 
deprecation period and the code will be removed in M* cycle.

the code removal is dependent on Aodh being gated on, released and 
packaged. it is also dependent on any upgrade requirements being documented.

the goals for a short deprecation is:
- to avoid a slow complicated divergence in code that will lead to 
difficult maintenance
- to allow time for packagers to package the new Aodh service
- to give operators, tracking the latest and greatest, the option of 
whether to upgrade to Aodh or not.

i hope that clarifies our intentions. this is our first split so if 
there are any noticeable gaps in logic, please feel free to chime in.

cheers,

-- 
gord