15:00:17 #startmeeting ceilometer 15:00:17 Meeting started Thu May 29 15:00:17 2014 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:21 Thanks 15:00:21 The meeting name has been set to 'ceilometer' 15:00:28 hey y'all 15:00:33 o/ 15:00:34 o/ 15:00:37 o/ 15:00:39 o/ 15:00:48 <_nadya_> o/ 15:01:19 o/ 15:01:38 o/ 15:01:59 k folks, lots to get thru' today ... 15:01:59 o/ 15:02:03 o/ 15:02:09 o/ 15:02:32 #topic "Quick apology" 15:02:34 o/ 15:02:43 ildikov: the floor is yours ... 15:02:53 murphi, alias me owes you an apology :) 15:03:18 eglynn promised me to kick me out of the Ceilo channel, if I show up on the meeting on my vacation 15:03:41 so I borrowed my good friend Murphy's name with a small modification 15:03:52 * eglynn adds murphi to the evergrowing /kick list :) 15:04:06 no worries :) 15:04:10 #topic Juno-1 blueprints coverage 15:04:25 #link https://launchpad.net/ceilometer/+milestone/juno-1 15:04:48 * nsaje jumps in late 15:05:05 looks like we're in not bad shape for j-1 15:05:20 ... a few BPs with outstanding specs 15:05:22 eglynn, we have some BP to be reviewed ;) 15:05:35 I mean code-reviewed) 15:05:38 ... i.e. currrently under review as DinaBelova points out, or else yet to be written 15:06:14 are those too for j-1? 15:06:25 <_nadya_> mm, should I rewrite old bp to spec? 15:07:09 _nadya_, well I may do it for you) 15:07:18 _nadya_: we decided to absolve any BPs that were already approved and already substantially implemented (e.g. as a result of being bumped from Icehouse) 15:07:21 _nadya_: IIRC that was the agreement that the unapproved/unstarted BPs should be rewritten in spec 15:07:47 <_nadya_> but it's started and on review 15:07:51 yep, only "fresh" BPs need to follow the new process 15:07:57 _nadya_, so as your one is almost done and approved... 15:08:04 np) 15:08:17 <_nadya_> ok, thanks for clarification 15:08:36 eglynn: how about approved but not started bp ? 15:08:40 _nadya_: yep ... so if it was previously approved and already substantially implemented, not really a good use of time to retrospecitively write a spec 15:09:15 llu-laptop: ... in that case, probably best to write a spec I think 15:09:55 does anyone have anything else they think merits a BP for j-1? 15:10:03 eglynn: ok. One of my colleagues what to implement the xen inspector bp which is already approved. I told him to write the spec, glad I didn't give hime the wrong answer 15:10:31 llu-laptop: cool, thanks for pointing him in the right direction :) 15:10:32 eglynn - well, we have tempest tests - in the tempest - we previously thought it'll be j1 15:10:40 ildikov: ... for example, does the docco work need a BP to track? 15:10:40 eglynn - just spoke with qa folks 15:10:53 eglynn: good question 15:11:09 eglynn: I do not know the process for manuals 15:11:24 eglynn - to merge our tests they need to do some extra work in the gate - so the tests will be in gate only at the end of next week 15:11:30 it's the best option we have) 15:11:35 eglynn: in the Dev doc there will not be a huge change, but if you want e to write a BP for it, I can do that 15:11:47 ildikov: can you ping annegentle to see what her preference is? 15:11:48 eglynn - but we may have our tepmest patches merged *before* 15:12:12 <_nadya_> DinaBelova: what work they need to do? 15:12:21 it's about the feature flags 15:12:31 eglynn: sure 15:12:36 they have the mechanism to skip tests in the icehouse job 15:12:43 _nadya_ but it's not sufficient 15:12:45 <_nadya_> DinaBelova: ah, you are talking about icehouse job? 15:12:47 DinaBelova, _nadya_: so we've an item on that later in the agenda 15:12:47 sorry for late; can't seem to remember to join here on time 15:13:05 eglynn, _nadya_ - yep, sorry to be impatient) 15:13:10 DinaBelova: np! 15:13:11 just as for the j1 15:13:49 DinaBelova: ... yeah on the j1 tracking, d'ya think the tempest work needs a fresh BP to track? 15:14:14 DinaBelova: ... or more like bug/RFE-level work-items on the QA side 15:14:33 eglynn - not the Bp in the ceilometer, I guess, but we have unclear BP for the tempest - that's why I'm writing specs now 15:14:54 and I wonder if it's a good idea to mark them j1 15:15:06 DinaBelova: a-ha, cool, those specs will land in qa-specs repo 15:15:10 yes 15:15:19 as said - not ceilo BPs, but related 15:15:33 DinaBelova: ... is j1 a bit ambitious, possibly? 15:15:38 I guess yes 15:15:48 some of the pathes will be landed for sure 15:15:53 patches* 15:16:16 but not all for sure - we have some things like events scenario - it's not started yet at all 15:16:22 <_nadya_> eglynn: we have all-in-one bp about 'basic ceilo test' and now there is the same about 'scenario (advanced) ceilo tests' 15:16:23 DinaBelova: ... so ambitious for j1 completion, but seems like some concrete progress definite in timeframe 15:16:39 eglynn, yes, exactly 15:16:45 cool 15:17:04 so just a quick reminder, juno-1 tag will be cut on June 12th 15:17:06 <_nadya_> DinaBelova: eglynn, we should be ready with basic in j1 15:17:30 _nadya_ - yes, I hope so - if we'll have no blockers from the qa folks 15:17:52 <_nadya_> DinaBelova: eglynn, scenario are for j2, j3 I believe 15:17:59 if they'll keep this "end of next week" estimation - it'll be so) 15:18:02 _nadya_, ++ 15:18:11 _nadya_: cool enough 15:18:43 * eglynn just wants to show definite progress to TC by the time of the j1 review of the gap coverage actions 15:19:00 (i.e. doesn't need to be 100% there by then) 15:19:23 eglynn, we'll have basic api tests landed I guess 15:19:28 and all other stuff - on review 15:19:43 or in progress (as for the scenarios) 15:19:54 DinaBelova: that would be a good outcome for j1 :) 15:20:13 BTW the new tag-driven milestone release process will buy us maybe a day or two extra development time for j1 15:20:19 ... *if * we choose to take it 15:20:35 ... however it's really just borrowing from the juno-2 milestone 15:20:42 ... a zero-sum scenario 15:22:06 next topic maybe? ;) 15:22:10 should we continue? 15:22:11 anything else anyone wants to bring up related to j2? 15:22:26 k, moving on in that case ... 15:22:28 eglynn, I guess we may go further) 15:22:31 eglynn: we have time for j2 ;) 15:22:32 #topic details of Juno mid-cycle meetup 15:22:49 jd__: the floor is yours :) 15:23:36 k, no jd__ ... let's punt that topic to next week 15:23:39 jd__, hehe) you here? 15:23:40 i think they have a holiday in France last i checked. 15:23:46 Yes they do 15:23:56 that's not the good reason for not being here) 15:23:57 gordc: a-ha, that explains it :) 15:24:00 :D 15:24:24 haha, I thought only the Swedish guys don't like working :) 15:24:32 #topic Performance tests as 3rd party CI 15:24:47 Hi) We decided to make performance test more automated 15:24:57 In thoughts it looked like job or scripts which uses ceilometer master and return results from profiler. For api, collector and agents performance. 15:25:09 ityaptin: ... so will it run periodically or on every commit? 15:25:38 voting to run this on demand 15:25:52 I think it shoul to run periodically, because for every commit we have some issues: 15:25:56 no need to run tests since every run requires manual analysis 15:25:59 These tests are too long for run them for each patchset 15:26:08 my vote is on periodically or close to release, I do not mean the last day of course :) 15:26:30 seems a mix of periodic and on-demand would be useful 15:26:34 or close to each mielstone? 15:26:50 s/miel/mile/ 15:27:06 could be run for every code set tagged for the milestone 15:27:12 also there is the issue with the testing env - if we speak about Jenkins job, for instance, there is only one node there, only standalone storage... 15:27:23 these results won't be really useful 15:27:27 ... so we see say the weekly trend over the cycle, but also run for each milestone/RC tag? 15:27:28 llu-laptop: +1, that'd be a good minimum 15:27:49 eglynn +1 15:27:50 eglynn, I guess it'll be cool 15:27:58 I think we may run these test for milestonces 15:28:05 speaking about the performance) 15:28:07 ityaptin: how will the results be reported? 15:28:20 llu-laptop: agree 15:28:22 we have blockers from QA folks, but we have porking tempest + ceilo 15:28:37 so gordc - your improvements were cool) 15:28:48 well, let's be patient) 15:29:01 about the performance testing 15:29:02 Now I write tests with profiler and it will collect tests results from profileng of runned process 15:29:17 ityaptin: ... if perf tests are decoupled from individual commits, then clearly results can't be reported as CI votes on gerrit? 15:29:22 DinaBelova: good to know... i haven't turned on multiple workers... debating if we should just to make sure it works. 15:29:44 ityaptin: "profiler" == "os-profiler by boris-42"? 15:29:53 eglynn, no 15:29:54 eglynn: no profiler -> cProfile 15:30:01 a-ha, k 15:30:07 os-profiler by boris-42 uses ceilo itself) 15:30:09 can we see the performance test results somewhere after each run? 15:30:10 not our variant) 15:30:12 eglynn, about commit - yes 15:30:36 prad_ - that's "todo" item - last times ityaptin published them himself 15:30:45 ah ok 15:30:52 ityaptin: ... so I'd like to see the results reported to a well-known/discoverable place 15:31:08 <_nadya_> regarding performance tests. As I understand, the strategy is still to be discussed. We have ityaptin's scripts but CI-configuration needs to be carefuly thought out 15:31:10 For examle, tests results for each milestones we can whos in wiki and at meetings 15:31:20 _nadya_, yes, exactly 15:31:41 eglynn, _nadya_ - the issue is about *where and how* to run these tests 15:32:03 ityaptin: ... what would be would for the test results to be easily discoverable 15:32:30 ityaptin: ... so given a tag, anyone would know where to go find the corresponding results 15:32:46 how about a special commit which never gets merged on gerrit to trigger that perf test? and perf test could post result as a 3rd party CI test 15:32:47 eglynn, _nadya_ we had the opportunity to create small virtual clusters as the testing labs internally - but I guess this should be somehow improved for the automated testing 15:33:21 ... cool, sounds like there are some aspects of this that need to be worked out in detail 15:33:23 <_nadya_> so by now, for this meeting, we just wanted to announce that we've started to work on it and ityaptin will be contact person. All suggestions about the place for results, db configurations are welcome 15:33:52 ... (a) when exactly to run, and (b) where & how to report results 15:34:16 eglynn, exactly 15:34:34 ityaptin: shall we return to this topic maybe next week to get closure on those two questions ^^^ 15:34:39 to have these tests on demand we need some nodes to work on -they should be specially configured, etc... 15:34:46 lots of infra questions really 15:34:57 <_nadya_> maybe it would be useful to discuss this one in 2 weeks 15:35:12 <_nadya_> *once 15:35:27 _nadya_, well, next week we may provide some update, but I guess clear answer will be in two ones 15:35:36 eglynn ^^ 15:35:43 eglynn, yes) we should to think this resuts, because now we have not complete answer for these questions 15:36:32 eglynn - is it ok for announcement? :) 15:36:32 _nadya_, DinaBelova, ityaptin: cool let's return to this topic next week so (... then every 2nd week maybe thereafter?) 15:36:41 #topic Tempest integration 15:36:45 yeah) 15:36:58 ... drum roll :) 15:37:01 so some news about this topic) 15:37:13 <_nadya_> pretty good news 15:37:18 ... the suspense is killing me! :) 15:37:32 1/ ceilo _ tempest works ok even without multiple collectors with gordc change for SQL backend 15:37:40 it's even not loaded 15:37:45 \o/ 15:37:46 I mean ceilometer 15:37:55 we used profiler to collect the measurements 15:37:58 gordc for the win! :) 15:38:00 bravo gordc 15:38:09 nice! 15:38:11 gordc: congrats :) 15:38:12 gordc++ 15:38:13 \o/ 15:38:15 so even with the additional load provided by profiler it's ok 15:38:15 gordc Congrats! 15:38:29 :) let's see how long it last 15:38:37 ... gordc kicks back and lights a cigar ;) 15:38:58 nah, also we need to say big THANK YOU to Vadim) 15:39:08 vrovachev: kudos! :) 15:39:14 i'll give sileht credit for having same thoughts as me. 15:39:27 <_nadya_> I believe that v1 dropping was helpful too :) 15:39:28 okay) 15:39:30 vrovachev: thanks for working on tests! 15:39:38 so we've goodness now on master 15:39:47 the next point is 2/ we had several discussions with qa folks 15:39:59 ... but still the problem of branchless Tempest, i.e. skipping testcases against stable/icehouse 15:40:09 eglynn, exactly) 15:40:10 eglynn: oh, thanks :S 15:40:36 TBH I'm a bit concerned about the ideas underpinning branchless tempest, i.e. that the API is just the API 15:40:57 eglynn - well, anyway we have the possibility for workaround here 15:41:10 eglynn: was the answer we had to get it working in icehouse too? 15:41:11 but as said - QA folks need some magic in gate to allow this 15:41:29 gordc, no, we persuaded QA folks that it's impossible 15:41:34 thank God 15:41:42 DinaBelova: ... so this is the feature flag idea we discussed with Sean yesterday? 15:41:55 eglynn, yes, but it looks like it's not so simple 15:42:08 as our flag will be ceilo specific 15:42:19 and as "tempest should be used for every cloud" 15:42:23 DinaBelova: cool cool. it might be possible to backport without dropping v1 but if we don't have to that's better. 15:42:35 they need one more level of abstraction speaking sabout feature flags 15:42:40 about* 15:42:44 gordc, ;) 15:42:58 eglynn, so they promised to make it work before the end of next week 15:43:00 gordc: yeah ... best to avoid the need to backport *every* perf improvement 15:43:09 and to land out tempest patches before 15:43:12 our* 15:43:18 eglynn: agreed. 15:43:24 DinaBelova: excellent! :) 15:43:26 ;) 15:43:50 they'll be just skipped before this "new abstraction level" will be done 15:43:55 and turned on after this 15:44:04 so news are quite good ones 15:44:39 well, it's almost the all I wanted to point here - I guess I mentioned all important moments 15:44:46 folks, do you have questions here? 15:44:52 DinaBelova: great news indeed! 15:45:11 DinaBelova: ... so the "new abstraction level" part, any clarity on what exactly the qa folks intend to do there? 15:45:11 looking forward to getting tempest tests up and running. :) 15:45:18 #info current ceilo master works with tempest 15:45:47 \o/ 15:45:49 #info tempest gating will be available ~end of next week due to QA infra blockers 15:45:57 eglynn, well 15:46:09 not so much really 15:46:31 I'm not really experienced in tempest to understand Sean in all the moments :-\ 15:46:47 DinaBelova: ... cool enough, it's all magic :) 15:46:54 eglynn: 15:46:56 [18:58:37] vrovachev: so the reality is we'll need the next level of feature grid in d-g to support this, however that won't happen until next week. But we can get the tempest bits close before then. 15:46:58 :) 15:47:31 ... if Sean's confident it'll be sorted within a week, then we can probably "take that to the bank" :) 15:47:36 ;) 15:47:59 so let's move on I guess 15:48:25 eglynn? 15:48:35 * eglynn wants to buy the team a virtual beer to mark this happy occasion :) 15:49:00 ... well everyone except _nadya_, just an orange juice for you! ;) 15:49:02 * DinaBelova saying cheers :) 15:49:16 <_nadya_> eglynn: thanks :) 15:49:25 very quickly on "DefCore impact of the lack of Tempest coverage in Havana" 15:49:44 ... so sadly the current DefCore effort is completely based on Havana 15:50:11 ... and our first Tempest coverage didn't land until Icehouse (i.e. the alarms tests IIRC) 15:50:34 eglynn, yep - alarms api afair 15:50:53 ... so as a result of the lack of Tempest coverage in H, no telemetry capabilities whatsoever listed in DefCode :( 15:50:55 https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf 15:51:21 heh :( 15:51:27 ... so we may need to think about backporting those alarm API tests to stable/havana in Tempest? 15:51:44 ... just an idea I wanted to throw out on the table 15:52:06 eglynn, well 15:52:22 vrovachev what do you think about it? 15:52:24 <_nadya_> eglynn: with Mongo we may try 15:52:37 we may have already missed the boat on that ... 15:52:45 ... but /me thinking it would not reflect well for ceilo to be completely absent from DefCore 15:52:58 DinaBelova: i thins, it's good idea :) 15:53:09 the only moment here is to check that they'll work 15:53:33 ... food for thought in any case, running out of time for today 15:53:38 ... so let's rush on 15:53:42 #topic TSDaaS/gnocchi update 15:54:03 no __jd :) 15:54:09 seeing jd__ isn't here, DinaBelova anything you wanted to bring up? 15:54:19 or just punt for today? 15:54:35 well, I was working on "how to run it???" 15:54:43 well, currently I have some success :) 15:54:48 is amalagon here? 15:54:57 yeap, I saw the discussions on IRC and anamalagon's README 15:55:05 DinaBelova: don't think so 15:55:27 eglynn, yes - so it's basically working - some gnocchi + swift stuff 15:55:43 not really easy to turn it on now, but I guess it'll be better 15:56:03 so the next steps will be to think about how it might be integrated with ceilo 15:56:10 DinaBelova: cool ... great to have that "getting started" info written down, easier for others to get involved and kick the tyres 15:56:19 eglynn, yes, for sure 15:56:27 I hope amalagon will do this soon 15:56:35 :) 15:56:40 with my help a little bit) 15:56:47 DinaBelova: yeap, we'll need another round of discussion on exactly what that integration will look like 15:56:56 eglynn, exaclty 15:56:57 #link https://review.openstack.org/96321 15:57:02 ^^^ README 15:57:05 and how it might fit with other features 15:57:10 events, for instance ;) 15:57:31 well, anyway, work is just started) 15:57:39 DinaBelova: cool, all good :) 15:57:41 #topic MONaaS update 15:57:43 I volunteer for the pipelinie part 15:57:51 <_nadya_> eglynn: where this round be held? 15:57:52 ildikov: great! :) 15:58:01 <_nadya_> eglynn: ML? 15:58:20 Hey everyone :) 15:58:22 _nadya_: well gerrit, ML, wiki, etherpad, IRC ... all over the place probably 15:58:31 aviau: hey 15:58:45 aviau: sorry we're up against the shot clock here 15:58:55 aviau you have two mins) 15:58:58 <_nadya_> eglynn: I just wanted not to be lost in this discussion 15:59:02 I'll try to go fast. 15:59:16 There was a lot of work done on the Etherpad, you can take a look at it. 15:59:21 #link https://etherpad.openstack.org/p/MONaaS 15:59:33 I also suggest you take a look at Nick Barcet's article, where he mentions some use cases for MONaaS 15:59:41 #link http://techs.enovance.com/7043/keep-openstack-weird 15:59:46 aviau: so the HP guys had a lot of feedback on the etherpad also 16:00:02 You might want to take a look at HP cloud-mon. A recently open-sourced MONaaS solution. It is an example of what we think MONaaS could look like. 16:00:05 aviau: they gave us an overview of their work at summit 16:00:08 #link https://github.com/hpcloud-mon/mon-arch 16:00:27 aviau: would it make sense for you to get involved with the HP project? 16:00:49 aviau: ... apparently it'll soon be moved to stackforge 16:01:13 About that, have started working on the blueprint template and I currently fail to see how we can fit monitoring in the currently proposed Telemetry program mission. 16:01:25 https://review.openstack.org/#/c/87526/5/reference/programs.yaml 16:01:47 what about moving to the Ceilo channel with this? 16:01:49 folks we've run out of time here, let's move it over to the #openstack-ceilometer channel 16:01:52 we ran out of time :( 16:01:58 bye! 16:02:04 #endmeeting ceilometer