15:01:05 <gordc> #startmeeting ceilometer
15:01:07 <openstack> Meeting started Thu Aug  6 15:01:05 2015 UTC and is due to finish in 60 minutes.  The chair is gordc. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:10 <openstack> The meeting name has been set to 'ceilometer'
15:01:23 <ildikov> o/
15:01:24 <llu-laptop> o/
15:01:33 <pradk> o/
15:01:37 <nadya> o/
15:01:43 <llu-laptop> we can start meeting without ending the previous one?
15:02:08 <gordc> llu-laptop: i don't know why it says thirdparty
15:02:17 <gordc> it's said that for a while now...
15:02:49 <eglynn> o/
15:02:57 <gordc> unless i actually did steal someone's meeting this time...
15:03:00 <pradk> i see ceilo in the topic
15:03:36 <gordc> pradk: yeah, but before i started it said. third party... *shrugs*
15:03:48 <gordc> no one seems to be yelling. so let's start.
15:04:10 <gordc> #topic recurring: roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Ceilometer/RoadMap
15:04:40 * cdent waves shyly
15:04:50 <gordc> right now i think the major item we're tracking still is the alarm split and getting it all integrated
15:05:04 <gordc> sileht: i think you've done some of that?
15:05:19 <sileht> I working on the gate job
15:05:33 <sileht> but I block because aodh auth is broken :(
15:05:45 <gordc> is this the keystonemiddlware stuff you mentioned?
15:05:49 <sileht> yes
15:06:09 <ildikov> gordc: will the packaging be done for Aodh too during this cycle?
15:06:13 <nadya> sileht: are you working on functional job, right? I mean moving tests to corresponding folder?
15:06:16 <gordc> argh. ok. well it's good we caught it now and not 2 weeks from now i gues.
15:06:44 <sileht> nadya, no I work on an 'integration' test ceilo+heat+aodh+gnocchi together
15:06:53 <gordc> ildikov: probably need to ask prad... i'm assuming it's done after rc ... and then puppet stuff is done the next cycle
15:07:03 <nadya> sileht: aha, much more interesting thing :)
15:07:43 <gordc> sileht: is the problem specific to aodh+gnocchi? or does it not matter what backend we use
15:08:08 <sileht> gordc, everything is broken :)
15:08:27 <gordc> lol well i guess that's easier to fix? maybe?
15:08:27 <sileht> gordc, it's no fun otherwise ;)
15:08:34 <gordc> hahah
15:08:44 <gordc> i don't think you understand what fun means.
15:08:46 <sileht> gordc, no really, but we have a workaround
15:09:03 <gordc> sileht: that's good to hear
15:09:05 <sileht> gordc, I have will bring the general issue to the ML
15:09:06 <pradk> ildikov, i have something packaged for aodh based on the git, ideally we want it on pypi so its more official
15:09:13 <sileht> have^W
15:09:28 <ildikov> gordc: pradk: ok, cool, tnx for the update
15:09:29 <pradk> ildikov, its here for now https://pkilambi.fedorapeople.org/openstack-aodh/
15:09:38 <gordc> cool cool. seems like we ahve aodh *relatively* under control
15:09:58 <cdent> that seems a fair statement
15:10:08 <ildikov> pradk: cool, tnx
15:10:31 <gordc> if we're still blocked next week, let me know and i can maybe escalate it.
15:11:00 <gordc> any other critical items we need to discuss in regards to Liberty?
15:11:10 <gordc> https://blueprints.launchpad.net/ceilometer/liberty
15:11:25 <pradk> declarative meters is blocked by devstack patch.. so if anyone can pull string and get that in we can merge :)
15:11:59 <pradk> gordc you poked qa you said right?
15:12:12 <gordc> someone with good rapport with qa?
15:12:15 <nadya> pradk: give me a link please
15:12:35 <pradk> nadya, https://review.openstack.org/#/c/207949/
15:12:53 <pradk> there are 3 patches depending on this in ceilo
15:13:06 <pradk> its a clean up patch due to change in approach
15:13:07 <gordc> pradk: i didn't ask.
15:13:13 <nadya> pradk: I'll ping the guy who will help us
15:13:19 <pradk> ty nadya !
15:13:21 <gordc> nadya: thanks!
15:13:32 * cdent will jiggle some people too
15:13:47 <pradk> cool
15:13:55 <gordc> nadya: https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-functional-tests with functional split merge is this blueprint complete?
15:14:04 <gordc> i don't know the exact scope of the bp
15:14:40 <nadya> gordc: Ilya is on vacation... In commit message in merge patch he stated that it's a first patch
15:14:42 <gordc> it mentions sql... but there's also another bp that specifically says sql
15:15:07 <gordc> https://blueprints.launchpad.net/ceilometer/+spec/sql-unit-tests-on-real-backend
15:15:35 <gordc> nadya: ok. i'll just leave it as is for now. feel free to mark complete if it is.
15:15:43 <nadya> Next step - separate classes and functions from moved files to right
15:15:43 <nadya> test types.
15:16:08 <nadya> gordc: ok
15:16:54 <gordc> k. anyone else have something to discuss regarding liberty?
15:17:23 <cdent> there's some progress on devstack and grenade plugins: this is bout ready: https://review.openstack.org/#/c/196441/
15:18:08 <cdent> It is basically correct now and it is possible to merge it before turning it on in any real sense
15:18:13 <gordc> cdent: we should just look at grenade part of experimental?
15:18:20 <cdent> yes, sadly
15:18:31 <gordc> k
15:18:31 <cdent> as far as I can tell most of those experimental jobs never work
15:18:35 * gordc ignores the red
15:18:57 <cdent> having it merged will make the next steps (on the grenad, devstack and infra sides) a little easier to move forward
15:19:14 <cdent> ideally we'd get all this done before liberty is done as that will make grenade related things cleaner
15:19:41 <gordc> cool. i'll take a look after meeting
15:19:46 <cdent> ossum, thanks
15:20:42 <gordc> #action review https://review.openstack.org/#/c/196441/
15:20:57 <gordc> any other stuff?
15:21:41 <gordc> #topic recurring: ceilometerclient release?
15:21:54 <gordc> i'm going to ask for a release beginning of next week
15:22:30 <gordc> we haven't had a release in a while and we merged some keystonev3 stuff... and aodh redirect so i think it'd be good to test it out.
15:22:50 <gordc> if someone needs something in next release let me know so i can hold off for abit.
15:23:07 <cdent> release early and often
15:23:34 <gordc> they took my release button away.
15:23:59 <gordc> #topic recurring: Gnocchi status
15:24:29 <cdent> influxdb in the house!
15:24:33 <cdent> (almost)
15:24:55 <nadya> (as the last 2 months...)
15:24:57 <gordc> lol way to kill the hype
15:25:40 <nadya> actually I saw +1 fom Jenkins, but jd__ cannot stop and continue send patches
15:25:41 <gordc> cdent: is it just logistics issue? i noticed the tests passed
15:25:57 <gordc> locally... i didn't try it with devstack
15:26:14 <cdent> gordc: It can't devstack yet, but you can make it happen by hand
15:26:38 <cdent> I'm not sure if jd__ and I are done squabling about the behavior of metricd or not
15:26:42 <cdent> I think that's the only hangup
15:27:19 <gordc> cool cool. not a blocker (from what i understand)... at least main functionality is there.
15:27:27 <gordc> thanks for the effort everyone
15:29:02 <gordc> good? good.
15:29:07 <gordc> #topic Open discussion
15:29:59 <eglynn> I added a late agenda item ...
15:30:04 <eglynn> "clarify aodh/ceilo-alarming divergence/consistency deprecation/deletion (eglynn)"
15:30:23 <eglynn> in relation to https://review.openstack.org/180908
15:30:32 <gordc> darn. added afgter my refresh
15:30:34 <eglynn> (versionedobjects adoption in ceilo)
15:30:36 <gordc> #topic clarify aodh/ceilo-alarming divergence/consistency deprecation/deletion (eglynn)
15:30:56 <eglynn> gordc: my bad, very late addition just as the meeting started
15:31:10 <eglynn> given the discussion on gerrit, seems it would be useful to explicitly state the policy here about aodh/ceilo-alarming consistency
15:31:27 <eglynn> do we require that all in-flight non-bugfix patches for ceilo-alarming are abandoned and re-proposed against aodh?
15:32:04 <gordc> eglynn: at the micycle we decided it wasn't worth maintaining both aodh and ceilometer-alarm since it was too much of a hassle
15:32:36 <eglynn> ok, so are we effectively guaranteeing the two codebases will diverge to extent that aodh -> ceilo-alarming:stable/liberty backports are harder than they need to be during mitaka?
15:33:25 <gordc> eglynn: i guess the question is how much maintenance of stable/liberty is required.
15:33:38 <gordc> aodh is being released independantly.
15:34:25 <gordc> that should make it so any one should be able to switch to it easier.
15:34:31 <eglynn> yeah ... I thought the whole reason for not deleting ceilo-alarming now was that we expected some distros to continue using ceilo-alarming for their liberty release?
15:35:13 <eglynn> but if we don't intend to maintain ceilo-alarming:stable/liberty, would it be a kindness to force those distros onto aodh?
15:35:25 <gordc> it's was partly a fallback... and partly because jasonamyers gave insight from ops pov that a random break with no warning would not be good.
15:36:17 <eglynn> OK, it that's the decision ... seems we should state an explicit policy
15:36:37 <eglynn> 1. abandon all in-flight non-bugfix patches for ceilo-alarming
15:36:41 * gordc looks back to midcycle notes.
15:37:03 <eglynn> 2. state that ceilo-alarming:stable/liberty will not be maintained
15:38:30 <gordc> sounds right. that was the decision we came to at midcycle...
15:38:50 <gordc> if there's issues now that we have it in practice i'm cool with revising
15:39:25 <cdent> I'm confused about point number 2: what's the issue with direct bug fixes to stable/liberty?
15:39:54 <gordc> cdent: they won't be straight backports.
15:40:00 <cdent> yes, so what?
15:40:08 <cdent> aodh is a different project
15:40:10 <eglynn> gordc: well TBH it seems like we're not doing the distros any favors by keeping ceilo-alarming until the liberty release, but not doing any stable/liberty maintainence on it afterwards
15:41:10 <eglynn> i.e. would it be better (long-term) for those distros if we forced them over to aodh before liberty?
15:41:18 <gordc> cdent: the same reason we chose to stop maintaining current code? it was too hard to keep both in sync.
15:41:28 <ildikov> eglynn: can we actually force them?
15:41:31 <cdent> we're not talking about keeping it in sync
15:41:47 <cdent> we're talking about accept bug fixes to stable/liberty if people have them
15:41:47 <eglynn> ildikov: well by deleting the old/duplicated code
15:41:53 <ildikov> eglynn: I'm not sure which option is more user firendly... :(
15:42:19 <eglynn> (or at least strongly discourage them from staying with the old code that we're not planning to maintain)
15:42:37 <gordc> tbh, i'm not sure what it looks like from distro pov.
15:42:50 <ildikov> eglynn: I would go for the strongly discourage version TBH
15:43:09 <gordc> the issue wasn't raise at midcycle when asked but if it's an issue, then i guess we need to think about it
15:43:45 <eglynn> gordc: maybe I've read too much into "i guess the question is how much maintenance of stable/liberty is required"
15:43:53 <pradk> from distro pov dont we have the control in forcing people to install aodh as being obsoleting ceilo-alarm?
15:43:56 <cdent> jason told me earlier today that he would not be able to attend today because of an internal meeting that rose up unexpected but his stance was something along the lines of "we need to be more concerned about the end users here, not the distros"
15:44:30 * eglynn interpreted that as meaning we wouldn't be backporting bugfixes from aodh to ceilo-alarming:stable/liberty
15:45:12 <eglynn> gordc: ... but maybe you meant more like: "it depends on how many/severe bugs show up after liberty"?
15:45:19 <gordc> pradk: from distro pov, how would it look like if aodh and ceilo-alarm both existed?
15:45:43 <pradk> gordc, they cant as they would conflict.. Aodh obsoletes ceilo-alarm
15:45:56 <gordc> eglynn: closer to that. the general idea was a fast-tracked deprecation of ceilo-alarm
15:46:17 <pradk> if someone upgrades from kilo -> Liberty ceilo-alarm would be removed and replaced by Aodh
15:46:26 <ildikov> but from distro perspective I guess it also matters that when we will be able to release Aodh
15:46:44 <gordc> pradk: so it's either one or the other?
15:46:56 <pradk> gordc, correct
15:47:01 <gordc> i guess that means if Aodh works, ceilo-alarm is dead.
15:47:34 <eglynn> gordc: agreed
15:47:47 <pradk> exactly, so regardless of if we maintain both alarm and aodh or not.. from distro pov, its Aodh if we upgarde as we replace ceilo-alarm
15:47:47 <gordc> the big with keeping ceilo-alarms around was in case we didn't get aodh working in time for liberty.
15:47:48 <eglynn> ... dead but continueing to exist in a zombie state? ;)
15:47:49 <ildikov> gordc: so currently we have the old code as a "backup" at least this was my understanding
15:48:01 <gordc> ildikov: right
15:48:11 <ildikov> gordc: ok
15:48:30 <eglynn> gordc: so if we do get Aodh working to everyone's satisfaction *before* liberty?
15:48:47 <eglynn> (I asked a similar question on gerrit)
15:49:30 <gordc> eglynn: the idea was to kill ceilo-alarm as long as aodh works
15:50:10 <cdent> one of the caveats there was that who gets to say it works? and one of the answers was "we'll only know that after it is released"
15:50:34 <gordc> seeing as it doesn't mean anything to exists when aodh exists, we can change our plan from "remove ceilo-alarms in M*" -> "remove ceilo-alarms when Aodh ready"
15:50:51 <ildikov> has anyone covered the docco part already? (I mean install, config and admin guides)
15:51:07 <eglynn> cdent, gordc: so "works" == fully operational in the gate etc.?
15:51:14 <gordc> ildikov:  the integration isn't complete yet so we can't actually docco the full process.
15:51:46 <pradk> iirc we were going to remove ceilo-alarm soon after liberty is cut ?
15:51:48 <ildikov> gordc: I know, but the docco will need to be updated soon after we consider this activity done
15:51:54 <gordc> cdent: i would guess the distro would decide too as they'll package using aodh... and will ignore ceilo-alarm (whether it exists or not)
15:52:17 <gordc> ildikov: yep.
15:52:27 <gordc> ildikov: we have a resource.
15:52:37 <gordc> or you can offer one.
15:52:44 <pradk> I'm working on fedora/rht packaging, not sure if anyone is looking at ubuntu side of things.. if not they need a fallback in liberty?
15:53:00 <eglynn> cdent: I agree that a sensible distro packager would do that, especially if there's a question mark around ceilo-alarming:stable/liberty maintanence
15:53:03 <ildikov> gordc: I can offer only myself :)
15:53:40 <gordc> ildikov: if you have time, feel free to take it.
15:54:23 <gordc> pradk: i'll check. it'd make sense that both distros did the same
15:54:42 <ildikov> gordc: ok, I will raise a flag, if I don't have the bandwidth or not enough, when we arrive to this point
15:55:03 <gordc> pradk: you'll probably want to sync with zigo
15:55:26 <pradk> gordc, sure, i'll check  with him
15:55:56 <gordc> pradk: when you package for fedora, that essentially means ceilo-alarm is dead.
15:56:00 <gordc> right?
15:56:36 <pradk> gordc, pretty much, if they update ceilp-alarm it will be replaces.. unless they blacklist it
15:56:51 <gordc> they would only be able to use celio-alarm if they compiled it themselves.
15:58:03 <gordc> so i don't want to maintain ceilo-alarms any longer than we need to... is there any issues from user pov if we remove it asap (even if that means in liberty)?
15:58:16 <gordc> from packaging, it apparently doens't matter.
15:58:41 <gordc> what other ways are there?
15:58:58 <eglynn> I would prefer removing if it's not going to be kept consistent or maintained
15:59:06 <pradk> gordc, yea i think majority are still on kilo or older and by the time puppetry ansible etc are in place and ready to consume Aodh should be in a stable state
15:59:24 <pradk> s/are still/would be still/
15:59:35 <gordc> we out of time... let's move over to openstack-ceilometer to discuss
15:59:41 <eglynn> but if we do keep for liberty, we would need some sort of explicit statement on maintenance
16:00:20 <gordc> eglynn: will answer in os-ceilometer
16:00:23 <gordc> thanks folks
16:00:25 <gordc> #endmeeting