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