14:11:55 #startmeeting Rally 14:11:56 Meeting started Mon Jun 15 14:11:55 2015 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:11:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:12:01 The meeting name has been set to 'rally' 14:12:10 hi! 14:12:13 e0ne: hi 14:12:19 andreykurilin: ping 14:12:36 bori-42: pong 14:14:16 amaretskiy: stpierre ping 14:14:22 boris-42: pong 14:14:25 boris-42: hi 14:14:32 okay let's start 14:14:32 o/ 14:14:35 \o 14:14:45 sorry for delay I was helping around fixing Neutron stuff 14:15:01 Hi) 14:15:06 hi 14:15:12 AlexeyKhodos_Nex: hi there 14:15:23 hi 14:15:36 adiantum: hi hi 14:15:47 hey 14:16:06 skraynev: hi there 14:16:21 skraynev: hi 14:16:57 #topic Rally gates are/were blocked 14:17:22 Okay recently few patches broke gates totally 14:17:44 and I spend a lot of time to unblock them 14:17:58 I think we should think about how to be more isolated from such mistakes 14:18:18 make all jobs non-voting ?) 14:18:23 amaretskiy: ya 14:18:26 andreykurilin: ^ 14:18:29 amaretskiy: sorry 14:18:35 i think in many cases we should try to convince other components to make their jobs voting 14:18:36 run rally jobs vs stable devstack 14:18:48 but that wouldn't have helped here 14:19:03 stpierre: they will just remove them=) 14:19:47 redixin: stable devstack is good, but it doesn't include all features, which we can test:( 14:20:08 we're in the rather unenviable position of depending on everyone else to not screw up, so i think our *first* course of action should be to help them not screw up. our fallback should be assuming that they will wantonly screw up, and insulating ourselves from that 14:20:13 redixin: andreykurilin we can test against some fixed patches? 14:20:32 sure 14:20:48 stpierre: so it takes usually a lot of time 14:21:00 stpierre: e.g. we will get sometimes blocked gates from days... 14:22:00 i understand, but if (for instance) nova proposes a change that breaks rally, that's not a problem if they have a voting rally job as part of their CI. if they refuse to do that, or circumvent it, then (and only then) should we try to find ways to insulate ourselves from nova. 14:22:39 that's not perfect, but rally is in a place where -- at least until the plugin split is complete -- we have to at least try to work with the other groups 14:22:54 How abouy to write something as sla that could revert patches?) 14:23:41 once the plugin split is really truly complete, then we can have separate jobs for rally (core) and the openstack plugins 14:23:47 Auto detecting that find last working master:-) 14:24:04 rvasilets__: it's quite hard task 14:24:32 rvasilets__: that could actually be a really awesome side project -- git bisect + rally == win 14:24:52 I can help:-) 14:24:57 stpierre: redixin andreykurilin another way is to have SMOKE mode 14:25:08 Its useful 14:25:13 https://github.com/openstack/rally/commit/f2d65679c4f0a753c20f7daffa48abe5552c2c6c 14:25:26 rvasilets__: ya it is useful but it s quite hard to automate 14:25:33 rvasilets__: because you have N repos 14:25:41 stpierre: we already have something like separated jobs for openstack(gate-rally-dsvm-neutron-rally, gate-rally-dsvm-rally-cinder, gate-rally-dsvm-rally-heat and etc) and rally core(gate-rally-dsvm-cli) 14:25:46 and N is growing, rapidly :) 14:26:04 stpierre: yep and such tasks are harder and harder 14:26:18 boris-42: smoke flag is good only when problem in performance of component. when it completly broken, it'll not help 14:26:20 andreykurilin: sorry, i meant completely (or nearly so) disjoint sets of jobs for the rally core repo, and the rally plugins repo 14:26:29 andreykurilin: usually it's not complete broken 14:26:47 andreykurilin: and such patches are really fast reverted.. 14:27:13 revert driven development 14:27:19 andreykurilin: ^_^ 14:27:43 andreykurilin: stpierre so what about smoke mode? 14:27:50 voting rally job will help people do not broke their projects. this also will help rally team do not suffer from bugs in other openstack projects 14:28:27 mestery: ^ 14:28:28 redixin: add voting jobs accross whole OpenStack is a hard task 14:28:41 andreykurilin: I will say impossible 14:29:01 why? why they want to continue with adding bugs to their projects? 14:29:04 andreykurilin: redixin btw in this case patch in devstack affected neutron 14:29:25 boris-42: http://memecrunch.com/meme/28CH6/impossibru-guy/image.png?w=400&c=1 14:29:30 redixin: they just don't belive that rally is testing well 14:29:31 boris-42: Ack, from our conversation this morning in #openstack-neutron 14:29:48 i think smoke mode is probably a step in the wrong direction. if the component teams refuse to ensure that their crap works, then we have to do it if we want our scenarios to be relevant. testing in smoke mode could result in us writing bogus scenarios, and then rally becomes less useful (and projects that look down their nose at rally already will claim to have another reason to do so) 14:29:54 mestery: we are just thinking if we will have voting jobs everywhere we won't get in such situation 14:30:23 boris-42: Agreed, we need to sort the concurrency issues and make it voting. 14:30:34 Non-voting jogs are challening because you hit issues like this 14:31:13 or we can keep an eye on non-voting jobs failures 14:31:14 mestery: so what can I say before those 2 bugs it was quite stable for a while 14:31:19 and give -1 for such patchsets 14:31:27 although even non-voting jobs can be helpful -- you can use the results to try to find the commit that broke something. if devstack had a non-voting rally job this could have been easier to troubleshoot 14:31:30 boris-42: Lets clean this up and then visit making it voting 14:31:31 redixin: usually it doen't work=) 14:31:49 mestery: ok great Neutron team can be good sample for the rest 14:32:18 stpierre: you are right. non-voting jobs can help troubleshooting 14:32:33 ++ 14:32:58 stpierre: but it would be much better if we will not need to troubleshoot:) 14:33:12 agreed :) 14:33:49 stpierre: try to add it=) 14:33:56 stpierre: to devstack ^_^ 14:34:01 ok 14:34:04 stpierre: I can send you diff) 14:34:19 awesome 14:34:28 i think we have some leverage right now, so let's try to use it 14:34:50 hi all, correct me if I'm wrong but a voting CI would have no effect on change being merged or not, only gating accounts have this ability? 14:35:16 wznoinsk: hm it's Jenkins jobs 14:35:21 job* 14:35:26 wznoinsk: so it will block merging 14:35:38 if it's under openstack jenkins then that's fine 14:36:39 wznoinsk, do you mean "-v" from third party job can't stop patch from merging? 14:37:17 redixin: yes, non of the account except for upstream openstack ejnkins has ability to stop a code proposal from merging 14:37:27 i thought any "-verified" makes patch impossible to merge 14:37:40 redixin: nope, that's what I wanted to clarify 14:37:58 I think it goes: silent account (no comments), commenting accoutn, voting account, gating account 14:38:56 otherwise any 3rd party ci with voting ability could prevent a change from being merged 14:39:14 and we know how well 3rd party ci are maintained (I have 2 myself :)) 14:39:48 apologies to inject this, please continue 14:40:14 wznoinsk: =) 14:40:15 wznoinsk: so in this case situation is different 14:40:24 boris-42: agreed 14:40:50 wznoinsk: seems like I have issues with internet... 14:41:49 okay so we discussed this part 14:41:53 let's move to next topics 14:42:30 #topic delays in next release 14:42:58 Unfortunately we didn't finish all refactorings to be able to cut new release 14:43:25 I am working now on some non backward compatible changes 14:43:26 they are here 14:43:34 https://review.openstack.org/#/c/191342/4 14:44:07 and actually replacing @base.scenario -> @scenario.configure() for all benchmark scenario [painful thing] 14:44:44 as well I believe we should replace rally/benchmark -> rally/task ? 14:45:48 redixin: stpierre andreykurilin amaretskiy ^ any thoughts? 14:46:07 "rally/task" sound good to me 14:46:26 but rally/benchmark currently contains lots of non-task stuff -- contexts, runners, SLAs, etc. 14:46:38 stpierre: ? 14:46:49 stpierre: actually task is all that.... 14:47:21 boris-42: rally/benchmark -> rally/task is good 14:47:23 stpierre: when you type rally task start you are using all of those things... 14:47:28 i guess that's true 14:47:37 * stpierre needs a cheat sheet for all of the rally vocabulary :/ 14:47:49 stpierre: so this change will remove one word from it... 14:48:06 stpierre: there won't be *benchmark* anymore... 14:48:59 so okay great 14:49:01 boris-42: it would be nice to add something like rally_glossary.rst 14:49:11 with all our words 14:49:18 andreykurilin: yep amaretskiy already asked few times 14:49:29 andreykurilin: but let's finish refactoring and remove/rename part of them 14:49:35 sure 14:49:42 and after that make glossary 14:50:01 #topic Open Discussion 14:50:07 do we have something to discuss? 14:50:14 Morning 14:50:31 any new about core rights for plugin maintainers? 14:50:36 news* 14:51:15 anyone has RA for CI infrastructure? 14:51:49 IlyaG: RA? 14:52:03 vponomaryov: https://github.com/openstack/rally/blob/master/doc/source/project_info.rst#plugin-core-reviewers 14:52:04 vponomaryov: core rights? 14:52:19 andreykurilin: there are more (I need to update that doc) 14:52:30 Physical hardware required for CI infrastructure ;) 14:52:58 IlyaG: heh I have only 2 servers... 14:53:02 boris-42: It looks like vponomaryov wants to be a plugin core of Manila :) 14:53:18 andreykurilin: ya he will be 14:53:32 andreykurilin: vponomaryov I would like to see how you are reviewing=) 14:53:34 it will work on honest word, rught? 14:53:40 vponomaryov: yep =( 14:53:46 nice 14:54:03 vponomaryov: so please don't merge patches out of scope of manila=) 14:54:04 boris-42: he should pay some $ to became a plugin core... :D 14:54:18 boris-42: actually I do not see good reason to be a core 14:54:29 vponomaryov: LOL=) 14:54:34 boris-42: because I am not allowed to +2 my own commits =) 14:54:53 vponomaryov: maybe there will be more people involved in manila benchmarks=) 14:55:43 it would be a very rare situation 14:56:21 vponomaryov: so then you can just review random stuff and become core of whole rally =) 14:57:10 so okay any other topics to discuss? 14:57:43 boris-42: review random patches and put random marks...hm...it reminds me something or someone 14:57:52 andreykurilin: LOL 14:58:23 andreykurilin: you became a core like that? =) 14:58:32 vponomaryov: xD 14:58:37 vponomaryov: sure! 14:58:48 okay see you guys next week 14:58:52 openstack-style review 14:59:02 #endmeeting