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