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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
