15:00:21 #startmeeting ceilometer 15:00:28 Meeting started Thu Jan 15 15:00:21 2015 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:32 The meeting name has been set to 'ceilometer' 15:00:32 o/ 15:00:43 o/ 15:00:50 o/ 15:00:54 o/ 15:00:59 o/ 15:01:01 hello 15:01:06 hey folks 15:01:10 #topic Kilo-2 status 15:01:10 g'morning 15:01:17 morning 15:01:23 #link https://launchpad.net/ceilometer/+milestone/kilo-2 15:01:31 <_elena_> o/ 15:01:51 we've made some progress in landing specs reviews 15:02:05 still a couple of BPs marked as blocked though 15:02:20 o/ 15:02:37 o/ 15:02:54 ceilometermiddleware has a +2 on https://review.openstack.org/142129 so should land soon 15:03:18 eglynn, hm there is one bug with my +2 - waiting for more cores https://bugs.launchpad.net/ceilometer/+bug/1372442 15:03:30 somehow I though it was already landed 15:03:35 thought* 15:03:43 DinaBelova: cool, I'll look after meeting 15:03:48 eglynn, thanks 15:03:54 might have to bump https://blueprints.launchpad.net/ceilometer/+spec/instance-autorestart if there's not more traction on it soon-ish 15:04:37 nealph: were you gonna to file a BP for the DB pipeline config part 1? 15:04:52 nealph: ... IIRC we discussed splitting this over kilo-2 and kilo-3 last week 15:05:05 eglynn: sorry, I thought https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-configuration-via-data-store was sufficient? 15:05:13 nealph: cool, thanks! 15:05:33 eglynn: added the linked https://blueprints.launchpad.net/ceilometer/+spec/configdb-api 15:05:39 as discussed. 15:05:45 for the k3 work. 15:06:19 nealph: excellent thanks ... it was just missing the targeting to kilo-2, done now 15:06:20 nealph, a-ha, as I remember you've discussed the work to be done as a part of https://blueprints.launchpad.net/ceilometer/+spec/configdb-api with idegtiarov 15:06:21 eglynn: my launchpad skillz are negligible...let me know if I need to do additiona. 15:06:52 nealph, let's I guess assign it to idegtiarov? 15:07:17 DinaBelova: the config API work assigned to be to idegtiarov? 15:07:38 eglynn: DinaBelova: let's hold off, I think fabiog and I need to chat offline on that... 15:07:42 eglynn, at least idegtiarov and nealph had the discussion (succeded as far as I remember) about it 15:07:47 nealph, ok 15:07:50 nealph: cool 15:08:06 it looks like I got it wrong a little bit 15:08:09 :) 15:08:30 DinaBelova: no, no, I think I jumped the gun on that. my fault. 15:08:46 nealph, np :) 15:09:15 cool, anything else on kilo-2? 15:09:34 gabbi stuff is pending acceptance into global requirements but that seems likely by the endof this week 15:09:49 cdent: excellent :) 15:10:27 #topic gnocchi update 15:10:47 interesting thread about gnocchi performance on the ML 15:10:50 #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054534.html 15:11:11 I think it's not clear to the casual observer that carbonara is a dev environment 15:11:33 eglynn, the only issue with this thread (for me, at least) is the name of mail-sender :) 15:12:10 cdent, I guess the overall issue with gnocchi now is lack of up-to-date documentation 15:12:17 with these moments described at well 15:12:18 I'm a bit worried about the slow progress wrt Ceilometer integration 15:12:28 we didn't do what we talked about for k1 and k2 is approaching without much progress 15:12:39 jd__ makes very good points 15:12:52 DinaBelova: the documentation is up-to-date, but it might be incomplete :) 15:13:00 jd__, yeah, sorry :) 15:13:04 wrong words 15:13:10 you stand corrected ;) 15:13:16 lol 15:13:38 other than that I'm pretty happy with the progress we made so far 15:14:02 jd__: I'll have a bit more time to contribute directly now that the juno-derived distro is mostly complete 15:14:02 and I'm gonna make efforts the next months to bring more attention to Gnocchi in general 15:14:17 eglynn: you see me glad and happy to hear that 15:14:35 jd__ - I'm kind of still concerned with one moment I've probably mentioned before about gnocchi -> ceilo integration. It's kind of very useful to store history of changes somehow... 15:14:46 and I see no simple way for doing this 15:14:53 jd__: can we put together a list of high priority gnocchi tasks over the next week? 15:14:56 (if we'll merge repos I mean) 15:15:09 DinaBelova: history of policy changes? 15:15:19 DinaBelova: git history do you mean? 15:15:25 gordc, I would way git history 15:15:27 eglynn, yeah 15:15:43 DinaBelova: I don't think merging repository is on the table righ tnow 15:16:02 jd__, I'm mostly about some future 15:16:23 and I'm pretty sure now that it's not gonna happen 15:16:24 DinaBelova: the stackforge/gnocchi repo could continue to exist in a "frozen" state after any merge (as a "fossil record" of the history) 15:16:59 eglynn, well, yeah, probably 15:17:01 there's like 0 point of merging an entire independant subsystem in a bigger one 15:17:20 jd__, well, if so, that's not the big deal 15:17:35 jd__, I just remember discussions about this before 15:17:35 yeah, having multiple repos is less of an issue in my mind than having separate core teams 15:17:40 right now the big deal is to make Gnocchi and Ceilometer work completely together, which is not yet done 15:18:07 eglynn: though we have separate core team in Oslo which is not a problem in the end 15:18:20 but it's not a problem we have right now 15:18:33 nellysmitt and idegtiarov are working on adding all resources (changes coming...) 15:18:40 it would be good for more ceilo cores to get involved in gnocchi reviewing, at least, IMO 15:18:45 DinaBelova: ah good to know, I didn't 15:19:03 jd__, well, they had lots of testing env issues... 15:19:03 eglynn: you said that ~2 months ago and that didn't happen, as I unfortunately expected :) 15:19:04 nellysmitt: was your OPW project topic finalized? 15:19:20 eglynn: i sense a subtle hint there. 15:19:29 I think we need to bring more attention on Gnocchi (and Ceilo) to have more people (even external to Ceilometer) starting to contribute 15:19:41 gordc: ... subtle, moi? ;) 15:19:47 * gordc will try to review today... was meaning to but got sidetracked. 15:19:48 eglynn, not yet - as I had long Xmas holidays it was frozen 15:19:53 eglynn, no project topic yet 15:19:59 I found one really interesting task although 15:20:10 you're right, of course, jd__ but what if we've asked for time and haven't been able to getit? 15:20:11 with making new resource adding more openstacky to gnocchi 15:20:31 eglynn, as now you need to go to 4 different places withough any stevedore, etc. to add new resource 15:20:31 cdent: I'm not blaming anyone, don't read me wrong 15:20:39 "more openstacky"? 15:20:48 eglynn, do you think it's a nice something to be done for gnocchi? 15:21:00 Oh, I don't think you are, I'm saying that as a group we need to agitate up the hierarchy to inform them of the need. 15:21:03 "more openstacky" == "fitting in with the usual openstack idioms"? 15:21:09 cdent: I'm actually not expecting ceilometer-core to review gnocchi, I think I would have better change to bring people from the outside of OpenStack right now 15:21:09 So that the need can be seen to be relevant 15:21:36 eglynn, more openstacky == using logical things like stevedore, etc. 15:21:49 Jd i plan on spending alot more time in the review of gnocchi -> ceil 15:21:56 jd__: do you mean domain experts in metrics stroage? 15:22:02 jd__: ... how about trying to get pauldix involved? 15:22:29 eglynn: pretty sure pauldix has other cats to whip, but I'd love to 15:22:44 eglynn: no I mean people who would start using Gnocchi to store metrics and who would have interest in it in general 15:23:00 you know, users who become developers, that's how FOSS work most of the time ;) 15:23:00 eglynn, do you thing some gnocchi resource adding logic improvement like I've mentioned will be nice thing for Nelly to work with? 15:23:01 jd__: ok 15:23:17 mesterm: sounds good. thanks for reviewing 15:23:40 DinaBelova: it would certainly be useful, but it there enough work for a 13-week internship? 15:24:10 eglynn, nope I suppose.... Although I don't have better ideas now 15:24:25 nellysmitt: how far thru' your 13 weeks are you now? 15:24:42 1 month + 1 week 15:24:51 eglynn, it you have some it'll be really cool 15:25:00 so 9 weeks left, ok 15:25:17 yeah, but I lost a lot of time solving issues 15:25:27 which were caused by hardware :( 15:25:49 that's unfortunate 15:25:54 BTW the final patches do not have to be landed within the internship period, as long as there's been good progress 15:26:39 the previous OPW intern for ceilo continued chipping away at her patches for a few months and finally got most of it landed 15:26:40 eglynn, I had also some idea about implementing driver for https://github.com/kairosdb/kairosdb 15:26:57 that's tsdb over cassandra 15:27:18 eglynn, althoguh that'll be going kind of really tricky 15:27:40 ok, that could be interesting, though we'd have to be careful about proliferation of drivers 15:28:01 eglynn, yeah, that's also the issue 15:28:11 DinaBelova: is there any more contained feature of the OpenTSDB driver that could be split off? 15:28:33 eglynn: I am working on some API and datastructure tweaks to improve batching greatly 15:28:33 DinaBelova: ... e.g. the kind of async expiry/downsampling logic you spoke about before? 15:28:41 fabiog: cool 15:28:57 eglynn, python code is almost ok now, as for the retention/downsampling I was already working on it - and that's pure Java 15:28:57 eglynn: I am planning to do a Google Hangout sometimes soon to check the approach is viable 15:29:40 DinaBelova: a-ha, ok 15:29:53 fabiog: sounds interesting 15:29:58 eglynn: and jd__ retention policies are per project/user combination 15:30:21 is that really necessary? what is the usecase of retaining a resource longer for a specific user within the same project? 15:30:58 fabiog: API tweaks on Gnocchi? 15:30:58 fabiog: you've lost me ... there's a single ArchivePolicy per Metric, no? 15:31:29 eglynn, well, may you please spend some time on if KairosDB driver will be the nice task? 15:31:33 eglynn: yes, but metric is linked to project/user combination through resources, isn't it the case? 15:31:51 eglynn they have python client as well 15:32:05 jd__: yes I want to decouple measures from metrics so we can batch them as they come without having to group them by metric 15:32:33 fabiog: you mean sending measures for several metrics in one HTTP request? 15:32:38 fabiog: so you meant retaining data for the same Metric name (e.g. cpu_util) for different resources of the same type (e.g. instances) for different periods? 15:32:39 yes 15:32:52 jd__: yes 15:33:12 fabiog: ok, I'm curious as I'm not sure it'd be an improvement, but I'd be glad to discuss if you've a patch or proto or something 15:33:35 eglynn: feel free to continue the agenda if there's any btw :) 15:33:46 jd__: give me a week or so and I will prepare a presentation 15:34:04 fabiog: ok, that retention flexiblity is provided by the gnocchi API ... but in practive I suspect ceilo will not usually be using that degree-of-freedom 15:34:10 jd__: I was meant to do that at the mid-cycle ... 15:34:24 fabiog: ... unless for example some subset of resources are consider higher priority than others 15:34:43 fabiog: ... e.g. running a retail site, as opposed to build farm 15:34:53 * nealph thinks that's an interesting concept 15:34:53 eglynn: right, but this is the cause of the batching restrictions IMHO 15:35:23 fabiog: a-ha, so you don't want to batch across metrics with different ArchivePolicies? 15:35:57 OK, this sounds like an interesting subject that we could debate at length on a hangout or a specs review or some-such 15:36:02 eglynn: wait ... I want to batch measures independently from its metrics 15:36:25 fabiog: OK, I'm missing the relevance of the variable retention policy in that case 15:37:03 eglynn: it is better I prepare my presentation and schedule a meeting. It is hard to explain it in IRC. I need pictures, data structures and so on :-) 15:37:14 fabiog: coolness, that makes sense 15:37:27 ... I look forward to getting an invite :) 15:37:54 k, let's move on, a few housekeeping items to cover 15:37:57 #topic Miscellaneous housekeeping 15:38:24 for those who didn't hear, we decided to cancel the midcycle meetup 15:38:45 ... as we didn't reach a quorum of contributors committed to attend 15:39:16 ... but let's try to cover the topics via remote collaboration instead over the coming weeks 15:40:17 there was a thread on the ML from ttx about changes to the L* design summit format 15:40:21 #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html 15:40:49 so we, as a project, will need to express some preferences for how we'd like to accomodated at summit 15:42:11 IIRc basically a mix of ... 15:42:19 (a) fishbowl-type sessions in larger spaces 15:42:29 (b) more focussed working sessions in smaller spaces 15:42:37 ... and (c) free-flowing contributor meetup style sessions 15:42:58 I'm thinking (a) is more appropriate for the large projects e.g. nova & neutron 15:43:21 which leaves us with (b) and possibly (c) as the best option for ceilometer? 15:43:29 eglynn: agreed 15:43:46 eglynn, I think so as well 15:43:56 I don't think we need 100 to 200 people for fishbowl 15:44:03 llu-laptop: I agree 15:44:06 eglynn: yeap, I don't feel myself as a fish either :) 15:44:30 so any objections to requesting mainly (b) for the ceilometer track? 15:44:44 How many sessions on ceil are we thinking? 15:44:52 just a question, if we don't apply for fishbowl, do we get enough timeslot for the working sessions we requires? 15:46:04 I am hoping there are some that are somewhat ops/implementation focused to address existing issues 15:46:08 cool with me 15:46:34 ^ both eglynn and mesterm suggestions 15:46:43 mesterm: historically we've gotten around 8-10 sessions ... but I suspect the competition for space will be more intense in the L* summit 15:47:01 (b) sounds fine 15:47:23 (b) looks good to me too 15:47:26 eglynn: sounds good 15:47:30 llu-laptop: I think applying for fishbowl time would only be appropriate if we really feel we can fill the space 15:47:56 BTW we had been jokingly calling the L* cycle "Lemming" 15:48:13 ... apparently though that's been removed from the list of candidate names 15:48:33 ... too easy for the haters to make jokes at our expense, apparently 15:49:25 Love, London, Liberty & Lizard on the list instead 15:49:38 my money is on Lizard 15:49:40 Lizard 15:49:47 snap :) 15:49:53 eglynn: lemmings are adorable now that i've googled it 15:49:58 love seems a little bit weird 15:50:06 what about liver.... everyone loves liver 15:50:15 gordc: LOL :) 15:50:17 * nealph grimaces 15:50:33 mesterm: ... preferably chopped :) 15:51:02 eglynn: but are we moving away from being something from the place, e.g. steet, neighborough etc ... 15:51:31 fabiog: I am wondering if London is a street in Vancouver 15:51:50 fabiog: I think it's still primarly placename-based, maybe loosening the definition a bit though 15:52:02 last item of housekeeping ... Use of spec proposal and feature proposal deadlines during kilo-3? 15:52:19 Thierry wants to have a lits of the deadlines each project is aiming for 15:52:52 eglynn: can you post the schedule again, please? 15:53:16 feb 5th kilo-2, 15:53:18 #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 15:53:25 eglynn: thanks 15:53:26 mar 19th, kilo-3 15:53:34 how about ... feature proposal freeze two weeks out from kilo-2, spec proposal freeze 4 weeks out? 15:54:39 feb 19th and mar 5th? 15:54:54 works for me... 15:54:57 yeah, that sounds right 15:54:59 cool 15:55:06 good to me 15:55:15 looks ok 15:55:50 #topic open discussion 15:56:12 anyone want to raise anything in the remaining few minutes? 15:57:05 working remote during what was the mid-cycle will be done maybe via etherpad? 15:57:48 mesterm: etherpads are one way, also fabiog is proposing a g+ hangout for his topic 15:58:07 mesterm: I think the person that proposed the topic will be in charge of organizing something 15:58:15 fabiog: agreed 15:58:28 i just dont want to miss anything :) 15:59:09 cool 15:59:10 mesterm: I will put my presentation schedule as topic for next meeting 15:59:28 fabiog: thanks 16:00:02 ok folks, outta time, let's call this a wrap ... thanks for your time! 16:00:11 #endmeeting ceilometer