15:01:12 #startmeeting ceilometer 15:01:13 Meeting started Thu Jun 5 15:01:12 2014 UTC and is due to finish in 60 minutes. The chair is eglynn_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:16 The meeting name has been set to 'ceilometer' 15:01:22 o/ 15:01:24 Hi! 15:01:33 o/ 15:01:34 hi all :) 15:01:36 o/ 15:01:38 o/ 15:01:40 DinaBelova: o/ \o 15:01:40 o/ 15:01:41 o/ 15:01:47 o/ 15:01:49 enikanorov_ :D 15:01:54 good afternoon / good morning / good night all! 15:02:05 #topic Juno-1 blueprints status 15:02:16 #link https://launchpad.net/ceilometer/+milestone/juno-1 15:03:08 <_nadya_> o/ 15:03:21 gordc: do you think we'll have enough in the v1 api removal & retry rationalization to declare victory on the sqla BP for juno-1? 15:03:23 https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql 15:03:50 eglynn_: i was going to ask same thing... 15:03:50 i.e. we could push the further improvements discussed with Mike Bayer out a 2nd dependent BP 15:04:02 (and target that 2nd BP at juno-2) 15:04:05 it's not fully realised but it's enough for testing to continue. 15:04:14 eglynn_: sounds like good plan. 15:04:30 i'm ok creating another bp and marking this one as complete 15:04:37 gordc: yeah, it brought it from unviable to viable so I think that's good enough to put a stake in the ground for j1 15:04:39 o/ 15:04:51 gordc: ... thanks if you could file that second BP, it would be great! 15:04:54 eglynn_: cool cool. i'll do that then. 15:05:04 gordc: thank you! 15:05:27 BTW folks we had a call yesterday evening with Mick Bayer, author of sqlalchemy 15:05:46 gordc steps him thru' the current schema and got some good feedback and pointers 15:06:05 * cdent waves 15:06:08 rough notes here ... https://etherpad.openstack.org/p/ceilometer-sqlalchemy-mike-bayer 15:06:10 great 15:06:26 (... a bit of a scramble of my initial email conversations with Mike, gordc's comments, and a summary of the discussion on the call itself) 15:06:54 i would hide my irc handle if i were Mike... i can see a lot of questions coming his way. 15:06:59 hehe :D My summary would be better if I had no connection issues :D 15:06:59 <_nadya_> just one plea from me is https://review.openstack.org/#/c/87249/ . Review is very old but bp has juno-1 target. I'm still ready (and able) to answer all your comments 15:07:01 _nadya_: are you confident of https://blueprints.launchpad.net/ceilometer/+spec/hbase-resource-rowkey-enhancement landing for juno-1? 15:07:18 <_nadya_> eglynn_: see my message above :) 15:07:34 _nadya_: cool 15:08:14 https://blueprints.launchpad.net/ceilometer/+spec/grenade-upgrade-testing is pending EmilienM's patch landing 15:08:20 eglynn_, and btw 15:08:27 _nadya_: I tried once looking at the patch before, but failed because I had zero knowledge of hbase 15:08:27 eglynn_ about _nadya_'s change 15:08:37 it improves hbase performance dramatically 15:08:50 <_nadya_> llu-laptop: yep, I understand, too specific change :( 15:09:00 so if we want to test performance of different backends, her change is vital 15:09:23 DinaBelova, _nadya_: excellent, we definitely need to get it for j-1 in that case 15:10:00 re. that grenade patch ... I discussed with Sean Dague on the -qa channel earlier 15:10:07 ... should be no remaining blockers other than review bandwidth, so confident it will land for j1 15:10:34 cdent will be proposing a corresponding BP spec also 15:10:44 eglynn_, yeah, already seen it - it's cool! 15:11:01 idegtiarov: how about https://blueprints.launchpad.net/ceilometer/+spec/hbase-events-feature ? 15:11:10 Yeah, I was stubbing that in the start to that grenade spec just before this meeting. 15:11:41 I'm sure it will require some judicious review as I only half know what I'm doing. 15:11:44 eglynn_, there is strange Jenkins error there.... gate is failing - one bug was fixed, so idegtiarov tried to recheck 15:11:45 idegtiarov: will this patch suffice to declare vistory on it? ... https://review.openstack.org/#/c/91408/ 15:11:49 we'll see what it was 15:11:59 DinaBelova: k 15:11:59 change is ready to be reviewed 15:12:14 <_nadya_> eglynn_: idegtiarov is working on this. I hope it will be ready 15:12:22 _nadya_: great! 15:12:26 <_nadya_> eglynn_: all tests passed locally 15:12:38 prad: what about https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-meter-lbaas ? 15:12:41 that's why Jenkins fail looks suspicious... 15:12:47 <_nadya_> eglynn_: we need several days for final version 15:12:54 o/ 15:12:54 I am working! Hope all will be done in time. 15:13:03 sileht, o/ 15:13:05 eglynn_, started working on it 15:13:10 _nadya_, idegtiarov: great, thanks! 15:13:15 o/ 15:13:36 prad: ... https://review.openstack.org/95784 is still WIP for now? (... worth getting eyes on?) 15:14:23 eglynn_, yes, worth taking a look.. i still need to incorporate the enum suggestion you had.. and working on unit tests and docs.. should have something by next week 15:15:01 eglynn_, yea left the sip as the spec was pending.. now that thats approved.. will have this for review by early next week 15:15:13 but early eyes wouldn't hurt if someone has time to look at it 15:15:28 prad: so for juno-1, we need to have it landed by say Tuesday next week 15:15:45 prad: (juno-1 tag to be cut on Thurs) 15:15:52 eglynn_, sure will try it get that in by then 15:15:59 to* 15:16:08 eglynn_, hehe, if gate will be ok :) 15:16:15 eglynn_ to the time of j1 :) 15:16:47 DinaBelova: well, we trust in the powers of the QA folks! :) 15:17:04 yeah, exactly :) 15:17:31 anyone anything else to add for j1? 15:17:40 have any one successfully reproduce the bug locally? 15:17:46 https://bugs.launchpad.net/ceilometer/+bug/1323524 15:17:47 Launchpad bug 1323524 in ceilometer "tests.alarm.test_rpc.TestRPCAlarmPartitionCoordination.test_ordination_allocate failed for timeout" [Medium,Confirmed] 15:18:09 llu-laptop: I couldn't, but didn't spend much time on it 15:18:47 llu-laptop: me neither... i assume it's related to this: https://bugs.launchpad.net/ceilometer/+bug/1321826 15:18:50 Launchpad bug 1321826 in ceilometer "periodic notifier unit test failure" [Medium,In progress] 15:18:50 llu-laptop: I was thinking we might have to bump it to j2 ... if it's one of those transient issues that may take unbounded time to track down 15:19:02 I couldn't either, thouh I run tox -e py27 quite lots of times these days due to another issue 15:19:11 seems like some oslo.messaging quirk 15:19:19 gordc: yeap, my thought also 15:19:19 eglynn_: agreed 15:19:26 k, let's bump it 15:19:42 #topic details of Juno mid-cycle meetup 15:19:58 ... brought to you by your gracious host, jd__ ;) 15:20:11 aye 15:20:20 #link https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 15:20:32 so all details should be on that wiki page 15:20:36 last time we had no opportunity to learn the results :D 15:20:43 if you got any question feel free to ask me as I'm organizing it mostly 15:20:47 any advice on local hotels? 15:21:04 eglynn_: good point, I can ask for that 15:21:15 jd__: cool, thanks! 15:21:17 jd__: how much to couchsurf at your place? 15:21:56 gordc, hehe :D 15:22:05 gordc: LoL 15:22:14 <_nadya_> doh :( guys, you are too cruel 15:22:17 lol 15:22:18 AirBnB Paris stylee ... LOL :) 15:22:31 good business model. 15:22:47 I'm sorry gordc you're not hot enough 15:23:02 jd__: hahah fair enough 15:23:05 jd__, probably some nice girl will be better :D 15:23:17 * jd__ high fives DinaBelova 15:23:31 anyway we alredy are 3 for Ceilometer on this sprint so that's cool 15:23:36 sadly sileht won't be able to join 15:23:50 really, that's a pity! 15:23:55 yep 15:24:02 he knows! 15:24:04 * sileht is sad 15:24:09 <_nadya_> +1 15:24:22 if you plan to come don't forget to update the wiki :) 15:24:28 * eglynn_ sad also :( 15:24:54 update the wiki so jd__ will know how many to make room for on his couch? 15:25:02 exactly 15:25:09 : 15:26:04 jd__: closer to the time, we could discuss a concrete agenda/goals etc.? 15:26:15 eglynn_: sounds like a good idea 15:26:27 jd__: cool 15:26:37 eglynn_, offtopic - idegtiarov change is failing due to https://bugs.launchpad.net/ceilometer/+bug/1323524 15:26:39 Launchpad bug 1323524 in ceilometer "tests.alarm.test_rpc.TestRPCAlarmPartitionCoordination.test_ordination_allocate failed for timeout" [Medium,Confirmed] 15:26:43 just checked it 15:27:02 DinaBelova: a-ha, that's the hard to reproduce bug mentioned above 15:27:08 DinaBelova: ... failing consistently? 15:27:08 yeah... 15:27:16 two times 15:27:28 lemme check it one more time if it is about this bug 15:27:38 yeah, it's it 15:27:41 eglynn_, DinaBelova I have introduced this bug 15:27:42 :( 15:27:55 k, we'll need to look into that ... let's move on for now tho' 15:27:59 ok 15:28:11 #topic Tempest integration - branchless Tempest: skipping testcases against stable/icehouse 15:28:32 so we'd some further discussions with mtreinish to clarify this 15:28:46 yeah, exactly 15:29:00 turns out that *both* a capabilities API *and* static test-skipping config are required 15:29:20 api change is trying to be merged 15:29:21 ... 15:29:25 22 hours 15:29:42 as for the devstack change it's almost merged 15:29:55 and there is tempest change - alsoalmost reviewed 15:30:12 vrovachev: ... do you mean the static test-skipping config? 15:30:33 eglynn_, yes, it's for the config 15:30:45 I mean devstack change 15:30:58 it sets needed flag - as Sean proposed to 15:31:25 summary/explanation of the test skipping approach for anyone interested is in http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2014-06-03.log 15:31:32 and after it'll be merged it'll be physical capability not to skip these tests 15:31:40 "we need *both* a discoverable API and config-driven test exclusion" 15:31:44 "... with the former used (indirectly) for public cloud testing, but *only* the latter relied upon in branchless tempest runs" 15:31:57 eglynn_, heh, yes :) 15:32:18 cool enough, sounds like all will be well once the gating Gods smile upon us :) 15:32:24 so I'll catch dtroyer to grab second +2 today 15:32:33 yes, exactly :) 15:32:39 DinaBelova: cool, thanks! 15:32:51 move on? 15:32:55 eglynn_, + 15:32:59 ok 15:32:59 #topic TSDaaS/gnocchi update 15:33:08 jd__: the floor is yours ... 15:33:16 thanks 15:33:27 so we've made good progress on the indexing part 15:33:41 cool 15:33:46 to the point you're now able to create, update, list and search for resources 15:34:00 the CI is in place too and working 15:34:06 gating against py27/py33 and postgresql 15:34:11 mysql is on its way 15:34:22 *cough*, *cough*, py26? 15:34:27 py26 too :) 15:34:36 jd__, please use more self-describing commit messages, btw ;) 15:34:36 thank you sir! :) 15:34:43 next steps would be: 15:34:44 <_nadya_> jd__: do we have an api spec? Maybe I've missed that 15:34:54 - start working in Ceilometer pushing things into Gnocchi 15:35:06 - dig a bit in the pandas usage and entity API to provide more features 15:35:24 amalagon: might be able to jump in there ^^^ 15:35:27 _nadya_: no, we should be able to generate it somehow from the code I would hope 15:35:39 but we can write it by hands for now if needed 15:35:56 (... to look into exponential smoothing and other black statistical arts) 15:36:00 jd__, well, good spec will help to write good code 15:36:01 so yeah anyone wanting to jump in welcome 15:36:03 right 15:36:15 eglynn_: definitely 15:36:36 excellent! 15:36:45 <_nadya_> jd__: I guess that if we start working on gnocchi we need to have a strong plan 15:36:48 BTW does the API feel like it converging on something relatively stable? 15:36:59 ... or still very much in flux? 15:37:05 <_nadya_> jd__: I mean we need to be sure that all customer needs will be covered 15:37:09 _nadya_: oh we need more people than a plan right now 15:37:21 eglynn_: so far it's converging as I'm not seeing any design issue 15:37:26 eglynn_: more eyes would help though 15:37:37 _nadya_: yeah my point about more eyes :) 15:37:59 but having API users will help toward that too 15:38:22 jd__: cool :) ... BTW I was also thinking of amalagon working on python-gnocchiclient 15:38:40 jd__: ... i,e, prolly best for her to concentrate on the most stable part of the API 15:38:58 yeah I was starting to look at python-ceilometerclient as a template 15:39:04 sounds good to me 15:39:09 eglynn_, if so, we definitely need API spec 15:39:15 to write the client 15:39:25 and keep it somehow stable 15:39:52 I think it would be a bad idea to stablize the api before having some significant use 15:39:54 DinaBelova: well the basic API interactions can be just derived from the code/wiki etc. 15:39:55 probably it's a good idea to start with it here before starting client work 15:39:58 otherwise we back ourselves into a corner 15:40:05 <_nadya_> yep, and to understand the direction and roadmap actually 15:40:26 well the API spec is the code 15:40:36 cdent: yep, we don't want to lock this down too early IMO 15:40:47 jd__, eglynn_, well, ok :) 15:40:57 eglynn_: yes, we shouldn't 15:41:13 I mean the code is pretty short and using pecan so it's pretty straightforward to have the spec from that 15:41:14 ... almost certain some API changes/requirements will only become clear once we start integrating it into ceilo core 15:41:22 and probably to auto generate it later 15:41:24 jd__: +1 15:42:01 <_nadya_> eglynn_: please correct m if I'm wrong, but am I right that v3api will be mostly for gnocchi? 15:42:39 _nadya_: yep my assumption is that the gnocchi will form the core of the v3 ceilometer API 15:43:32 <_nadya_> eglynn_: it's very big change and imho we need some poc, specs, glossary before implementing that 15:43:45 ... that said, we've yet to work out the details of bringing the gnocchi code into ceilo 15:44:06 ... issues like v2/v3 co-existence, migration of legacy data etc. 15:44:33 right now we need to start using it by feeding data from Ceilometer 15:44:48 then we'll be able to figure the rest out 15:45:12 jd__: yeah ... maybe some or all of those questions ^^^ would be relevant to discuss at the Paris sprint? 15:45:24 eglynn_: sure 15:45:37 <_nadya_> eglynn_, jd__, ok, and what's the plan? Who is working on this? only jd__? 15:45:38 I'd love to spend time on that during the sprint :) 15:45:50 cool ... depends also on the rate of progress before then, I guess 15:45:54 yes 15:46:04 _nadya_: for now, mostly me and DinaBelova's helping too 15:46:30 also ildikov has expressed an interest in working on the ceilo core integration part 15:46:33 and amalagon should do some stuff too 15:46:38 yep 15:46:43 :) yes! 15:46:46 <_nadya_> eglynn_, jd__, I'm just trying to figure out, sorry for noise :) 15:46:51 _nadya_: np 15:46:52 np! 15:47:11 anyway I've a long list of things to do etc wrt gnocchi so if you want to help and are bored, just come to me 15:47:18 :-) 15:47:21 jd__: cool :) 15:47:31 anything else on TSD? 15:47:42 that's all for me 15:47:42 jd__: is that list on the web anywhere? 15:47:45 <_nadya_> jd__: maybe you show us the list? 15:47:57 cdent: it is now :) 15:48:01 _nadya_, cdent: I had a gist but it's already outdated 15:48:12 I don't maintain a list nobody's going to read :D 15:48:32 jd__, you had https://gist.github.com/jd/229ab8211aa9a6b547de 15:48:40 thanks DinaBelova 15:48:49 and most of that is implemented actually 15:49:00 <_nadya_> jd__: am I right that first step is POC and it has 2 items: 1. Gnocchi code itself, 2. Integration with Ceilometer 15:49:37 _nadya_: 1. is pretty covered now I'd think but 2. is the most interesting one 15:50:47 <_nadya_> jd__: after 2. you we may be able to create API spec, discuss that? 15:50:47 _nadya_: there's also a third step ... 3. Migration of legacy data / deprecation path for v3 15:51:09 <_nadya_> jd__: *we may :) 15:51:25 _nadya_: but some or all of that step #3 may be pushed out to the Kepler cycle 15:51:26 _nadya_: the API is already there 15:51:42 * eglynn_ makes assumptions on the outcome of the K* naming poll 15:51:49 haha Kepler 15:52:29 at what step we write integration tests? 15:52:37 <_nadya_> eglynn_, jd__, are you gonna merge smth into Ceilometer master before api spec and all these conservative stuff? 15:53:03 _nadya_: dunnow yet 15:53:14 <_nadya_> eglynn_, jd__, it's still not clear for me, is this POC or...? 15:53:14 _nadya_: what format do you expect the API spec in? 15:53:34 _nadya_: we could easily derive something basic from the code 15:53:37 _nadya_: it's not POC, it's code that works and that's going to be production ready at some point 15:53:45 where the code will belong is another issue 15:53:58 but not very important anyway 15:54:03 <_nadya_> jd__: ok, I see your point 15:54:06 eglynn_, well the thing here is about the fact that just created API probably can't satisfy the all use cases 15:54:09 and all needs 15:54:26 jd__: my initial thought was to bring it into the ceilo repo once the initial rapid iteration/innovation phase is done 15:54:29 DinaBelova: well then someone should tell us why :) 15:54:47 jd__: ... are you thinking otherwise? 15:55:16 DinaBelova: so let's identify the missing use-cases 15:55:18 eglynn_: yeah that's a possibility, I'm also thinking that since it has no use of any part of the current Ceilometer code base it should stay autonomous as it can be used without the rest of ceilometer too 15:55:28 eglynn_: I think it's something to discuss in a month around beers 15:55:44 jd__: fair nuffski :) 15:56:19 DinaBelova: ... my feeling is that many of the missing usecases will be shaken out during the ceilo core integration phase 15:56:39 <_nadya_> eglynn_: about format. I expect examples at least 15:57:03 _nadya_: do you want to try to write the specs and the examples? 15:57:03 jd__: ... but either way, will need at least to be under the Telemetry program umbrella, right? 15:57:11 eglynn_: definitely! 15:57:20 jd__: cool 15:57:36 <_nadya_> jd__: honestly, I wish I could :( 15:57:40 eglynn_, I just think that or other backends (and probably use cases, etc) it might not be ready - and that't why I think some additional planning and at least more community noise about this will be cool 15:57:43 heh 15:58:16 _nadya_, DinaBelova: folks with misgivings about this approach, let's try to gather some *specific* concerns on an etherpad before next week's meeting 15:58:20 _nadya_: haaaa I knew you were just doing your wishlist for your next birthday or something! ;) 15:58:50 I agree with eglynn_, "thinking that it might not be ok" is not gonna help 15:58:56 I want facts and use cases. 15:59:17 _nadya_, DinaBelova: that way we can structure the discussion, and knock down any issues that we have answers for already 15:59:29 well, ok, let's close this discussion for now 15:59:30 <_nadya_> jd__: yep, for my baby birthday:) 15:59:35 hour's up 15:59:57 #topic Discussion about Alarm Management design for Horizon 16:00:05 eglynn_ can you post the etherpad link for the discussion, please 16:00:06 not much more to say than ... 16:00:08 _nadya_: :-) 16:00:11 discussed in detail on the ML http://lists.openstack.org/pipermail/openstack-dev/2014-June/036627.html : Liz Blanchard to come back with another iteration next week 16:00:21 #link https://etherpad.openstack.org/p/alarm-management-page-design-discussion 16:00:44 I'll be working on the horizon side so any comments/feedback will be appreciated. 16:00:50 ^^^ further discussion should probably wait on Liz Blancard's next version of the wireframes 16:00:58 cmart: cool 16:01:09 k, we're over-time here 16:01:17 cmart: happy to punt this on to next week? 16:01:30 eglynn_: sure! no problem! 16:01:38 cmart: thank you sir! 16:01:49 thanks all for a productive discussion! 16:01:55 thanks! 16:01:56 #endmeeting ceilometer