13:53:14 #startmeeting jjb 13:53:15 Meeting started Fri Sep 8 13:53:14 2017 UTC and is due to finish in 60 minutes. The chair is zxiiro. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:53:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:53:18 The meeting name has been set to 'jjb' 13:53:26 #chair waynr electrofelix 13:53:27 Current chairs: electrofelix waynr zxiiro 13:53:45 #topic jjb-2.0 13:54:11 I guess this is really our only topic at the moment unless someone else wants us to discuss something later? 13:54:43 electrofelix: so I think we should get this https://review.openstack.org/333076 landed asap before another patch is merged that breaks this again. 13:54:47 hmm wasn't there someone else were were considering as a jjb core a month or two ago? did that ever happen? 13:55:05 s/er w/ w/ 13:56:17 I was hoping to understand the purpose of the __deepcopy__ a bit more 13:56:20 just looked at the last meetings notes I don't see it 13:56:45 #info zxiiro thinks https://review.openstack.org/333076 should land asap 13:57:00 #info electrofelix wants to understand the purpose of __deepcopy__ a bit more 13:57:12 #action electrofelix to review https://review.openstack.org/333076 13:57:15 electrofelix: ok 13:57:18 #info waynr also thinks https://review.openstack.org/333076 should land sooner rather than later 13:58:27 #link https://review.openstack.org/#/q/status:open+project:openstack-infra/jenkins-job-builder+branch:master+topic:2.0-config-format 2.0 config format 13:58:41 waynr: electrofelix: ^ I think we decided to go with this? if so we should probably merge those patches 13:58:58 looks like there's a few merge conflicts for 3 of the patches. I can look into fixing that 13:59:11 #action zxiiro to resolve merge conflicts in https://review.openstack.org/#/q/status:open+project:openstack-infra/jenkins-job-builder+branch:master+topic:2.0-config-format 13:59:38 i can review those patches 14:00:17 might need reminders occasionally though ;) 14:00:18 zxiiro: I'm go with that, I'll start reviewing and will look out for the updates 14:00:26 sounds good 14:00:40 #action electrofelix & waynr to review 2.0-config-format patches 14:00:52 #link https://etherpad.openstack.org/p/jjb_api_v2.0 EtherPad of JJB 2.0 items 14:01:20 ok i think this is the last thing... electrofelix, waynr anything from the etherpad we want to discuss? 14:01:28 waynr: can you help me understand what's happening with __deepcopy__, what changed to require it? 14:01:35 guess we can discuss after the meeting 14:02:25 yeah i can go over that with you 14:02:33 during meeting or not 14:02:42 yeah we can talk about that now too 14:02:49 electrofelix: there was an email thread about it 14:02:50 i have to look it over again myself actually but i remember thinking it looked legit 14:04:03 waynr: was it not added recently? 14:04:34 electrofelix: the jinja patch needs it. Let me look up the email thread... 14:04:36 ah found it 14:04:45 electrofelix: oh? you got it? ok 14:09:54 Thanh Ha proposed openstack-infra/jenkins-job-builder master: Default groovy-postbuild to newest plugin format https://review.openstack.org/478372 14:11:35 Thanh Ha proposed openstack-infra/jenkins-job-builder master: Default slack to newest plugin config format https://review.openstack.org/478669 14:12:48 Thanh Ha proposed openstack-infra/jenkins-job-builder master: Default conditional-publisher to newest plugin format https://review.openstack.org/478378 14:13:01 electrofelix: waynr alright I fixed the 3 merge conflicts in the meantime. 14:13:26 anything else we want to discuss during the meeting? 14:14:31 electrofelix: I think the only other thing for JJB 2.0 is you mentioned you wanted to redo the config plugin system. Any progress on that? 14:17:46 yes, just not quite ready with the second patch, I almost forgot I had a question on it before I made a change 14:19:07 https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/helpers.py#L490 14:20:08 with the changes we've made to get plugin configuration information from specific plugin sections, I think this __future__ section should be dropped for the v2 release for individual plugin behaviour and instead added to the two plugins it affects 14:20:50 agreed. I think that's the right thing to do 14:21:02 waynr: ^ 14:21:26 as in a) switch it to default to taking the order from the yaml, and b) place the ability to use the old behaviour under "[plugin 'trigger_parameter...'] use_old_param_order = True" 14:21:52 or something like that, that was the last thing blocking ensuring that only the 'plugins' namespace needed to be passed to the plugins 14:23:12 that sounds good to me 14:24:18 well it'll break JJB for my ex coworkers but all they will have to do is avoid upgrading or chang their config files 14:24:40 were they using that option? 14:25:08 #info electrofelix asks if we should move param order setting to inside plugin sections for V2 14:25:27 or rather were they using trigger parameterized plugins and relying on the old behaviour of using the order defined in the code for the precedence of the parameters? 14:25:52 #agreed We will move the param order config into plugins section. 14:25:55 oh wait 14:26:26 nevermind, i was confused...i was misremembering something and misreading what you wrote 14:26:35 it won't break anything for excoworkers of mine 14:26:48 as in predefined-parameters would be overridden by current-parameters even if the yaml put it afterwards 14:27:14 yeah, I just realised it might cause you to think I meant about the project params precedence order ;) 14:27:41 yah i see what you mean now 14:30:32 electrofelix: I feel confused now. so currently if someone lists a parameter last it will take precedence over the same parameter if it's defined above? 14:30:39 electrofelix: so with the change what happens? 14:30:53 electrofelix: it will take the first defined parameter listed? 14:32:05 zxiiro: in the trigger parameter plugins, the original code hardcoded the order the XML was emitted for each of the possible settings, however Jenkins allowed you to order them to control which ones would override others and thus control the value of the parameter passed to the triggered build 14:33:21 so a user might assume that they could order the yaml definition for that plugin in the same way to decide that the can pass through 'current-parameters', and then override a single parameter by placing the 'predefined-parameter' block afterwards 14:33:53 unfortunately this was not supported by the code at the time and instead it would enforce a specific order https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/helpers.py#L475-L486 14:34:27 electrofelix: oh i see. ok understood 14:34:56 So to change it to allow it to be controlled based on the order the user would specify to match what jenkins allowed, and at the same time not break any existing ones needed to allow switching between old hardcoded order and new user defined order 14:34:58 ;) 14:35:34 i think i never noticed this because i almost exclusively use only string parameters 14:36:12 do you pass parameters to downstream jobs? 14:36:25 yes 14:37:15 in that case i almost exclusively run only paramters from property files 14:39:30 well anyway i agree with dispensing with the __future__ config section in favor of the plugin specific config section 14:40:08 Yeah. As long as we document it. I think it's fair game for V2 14:41:31 ok anything else to discuss? If I'm correct I think V2 is just blocked on 3 things at the moment: 14:41:31 1) YAML Parser patch 14:41:31 2) Plugin namespace config 14:41:32 3) 2.0-config-format 14:41:42 which all have action items so I think we're on track to getting 2.0 out. 14:42:16 if we can get 1) and 3) merged soon we'll be a little closer. 14:42:54 electrofelix: think you can get YAML Parser patch in today? should we try to iron it out now that everyone's here? 14:43:48 #action electrofelix to continue working on plugin namespace config patch 14:44:08 just approved, I'd been experimenting with it as we talked and read back over the email thread as well 14:44:25 awesome 14:44:38 alright if there's nothing else I guess we can end the meeting? 14:45:43 +1 14:45:48 I think I'm good with all of the reviews for '3', so I'll try to get something up soon for '2' 14:45:59 great. sounds good 14:46:01 #endmeeting