18:05:09 #startmeeting 18:05:09 Let the Jenkins meeting commence! 18:05:31 #charis rtyler hare_brain 18:05:48 #info https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda 18:05:57 #topic Recap of actions 18:06:11 i have question from missed meetings 18:06:18 ga 18:06:30 Build/publisher steps & AbortException handling https://github.com/jenkinsci/jenkins/pull/1577 18:06:37 #topic http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-04-01-18.02.html 18:06:44 oops 18:06:49 #topic Recap of actions 18:06:51 #info http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-04-01-18.02.html 18:07:17 KostyaSha: OK, I'll add it to the end 18:08:04 #action kohsuke to still write to Christina 18:08:16 "kohsuke to log #jenkins-infra" 18:08:33 how did we invite the current logger to this channel? 18:08:52 echelog 18:09:08 try /invite from infra channel 18:09:13 maybe it supported... 18:09:30 oh but echelog isn't here 18:09:31 If you wish to have your channel on Freenode logged or have any other inquiries, please mail me at: brian@matzon.dk. 18:09:31 If you wish to have your channel on Freenode logged or have any other inquiries, please mail me at: brian@matzon.dk. 18:09:50 looks like we lost that logger since April 13th 18:10:01 see http://echelog.com/logs/browse/jenkins/1429048800 18:10:21 All right, so I really need to write to that address 18:10:24 just wrote email to this person :) 18:10:36 great, thanks KostyaSha 18:10:55 CC infra@lists.jenkins-ci.org for extra credit 18:11:06 "danielbeck to ask oleg if he can hack ircbot to do this" 18:11:14 do what? let me see... 18:11:33 "we'll run jenkins-admin bot also in #jenkins-infra and restrict destructive commands to people with +v on #jenkins-infra" 18:11:39 oleg-nenashev: ^^ ? 18:11:41 I have not received anything from @daniel-beck 18:11:44 is that something we can ask you to take on? 18:11:47 kohsuke, i have some suggestions about bot from missed meeting 18:11:51 BTW, +1 for it 18:12:01 KostyaSha: sure, 18:12:10 kohsuke, if you fear about logging of bot actions, then infra may have logging server and bot may push to it 18:12:31 I've made several generalisation improvements in the bot, so we can easily launch it against INFRA 18:12:51 oleg-nenashev: so the context of that conversation from the last meeting is that ... 18:13:07 jenkins-admin bot has some commands that are more destructive than others 18:13:12 (such as renaming components) 18:13:32 and to do access control on those commands, we wanted jenkins-admin to join #jenkins-infra, and ... 18:13:40 only allow people with the voice in #jenkins-infra to run those commands 18:13:49 Ahh, got it 18:13:58 So not much to do with the INFRA project on JIRA, just to be on the same page. 18:14:14 KostyaSha: you mean we can run our own IRC logging service? 18:14:31 The feature can be added to the bot 18:14:39 kohsuke, i think just logging server, but then we can push any king of logging to it 18:14:46 *kind 18:15:07 kohsuke: Is there any urgency regarding the feature? 18:15:10 infra related commands, just irc and etc... 18:15:17 https://botbot.me/ works pretty good 18:15:37 I think we've been mostly happy with echelog, so my suggestion would be to wait to hear back from them before taking it onto ourselves 18:15:46 example: https://botbot.me/freenode/chef/ 18:15:53 I'm trying to offload services to others, and focus on smaller number of things. 18:16:24 kohsuke, searching in echangelog is bad 18:17:04 Err0: KostyaSha: but if you guys want to come up with a Docker container that packs the bot, I can get that deployed 18:17:27 botbot.me does look more beautiful than echelog, I agree 18:17:56 oh we could just request our channel be logged from botbot.em 18:18:22 https://github.com/BotBotMe 18:18:43 kohsuke, we can log in to bots ;) 18:18:51 in both 18:19:06 more bots against humans :) 18:19:22 all right, so I'll submit requests to botbot.me 18:19:32 and KostyaSha will hopefully get echelog back for us 18:19:40 And if we have two log bots, well, more the merrier. 18:19:49 ok, because i used wrong grammar tense in my sentence :) 18:20:03 here is the docker container: https://registry.hub.docker.com/u/gwadeloop/botbotbot/ 18:20:07 Moving on to next action... 18:20:17 Kamran to look into adding MEETING issue creation to robobutler 18:20:58 then "danielbeck to ask for ideas on improving the documentation on the dev list" 18:21:03 I guess danielbeck isn't here today 18:21:41 ndeloof to do the move [of Jenkins docker repo from cloudbees to jenkinsci] 18:21:46 Let me see, is it still there? 18:22:07 Yup, it's still there: https://github.com/cloudbees/jenkins-ci.org-docker 18:22:21 kohsuke, documentation for docker<->jenkinsci interaction will be appreciated 18:22:40 in case ndeloof dissappear so at least we will know what to do and how it works 18:22:40 Let me ask this repository be transferred to jenkinsci 18:24:10 We can just fork it, but if I'm lucky this gets done in 5 mins. 18:24:30 moving on to the next action... 18:24:37 "danielbeck to figure out how to get rid of clone in Jira" but he isn't here 18:24:42 kohsuke to disable mirror.bit.edu.cn 18:25:23 ha, since then this mirror came back into action: http://mirrors.jenkins-ci.org/status.html 18:25:57 Do we still want to kill it? 18:26:01 my eyes... 18:26:10 like 90' 18:26:14 hah. successfully using a bunch of jenkins jobs just for VM provisioning with libvirt/qemu/kvm, including automatic integration into the VPN and assignment of IP, and assignment of a DNS name, all via seperate jenkins jobs triggering around. 18:26:42 it's quite useful. 18:26:49 arminius, sorry meeting is going on this channel, try ask your question after meeting 18:27:15 I'm going to punt on this until danielbeck comes back 18:27:26 Maybe they saw this and fixed something on their side 18:27:31 oh my apologies, didn't want to disturb anything ongoing. sorry. 18:28:07 #action danielbeck to reconfirm if we should still remove mirror.bit.edu.cn given that it appears to be functioning again 18:28:16 Project jenkins_main_trunk build #4086: FAILURE in 3 hr 0 min: http://ci.jenkins-ci.org/job/jenkins_main_trunk/4086/ 18:28:16 * Stephen Connolly: [FIXED JENKINS-27708][FIXED JENKINS-27871] Ensure that identification of blocked tasks is using the live state. 18:28:17 * o.v.nenashev: [JENKINS-27871] - Added a direct unit test for the issue 18:28:19 JENKINS-27708:Concurrent build limits not honored on Jenkins 1.607 (Open) https://issues.jenkins-ci.org/browse/JENKINS-27708 18:28:21 JENKINS-27871:Block on upstream projects does not work (Open) https://issues.jenkins-ci.org/browse/JENKINS-27871 18:28:37 All right, so that's the recap 18:28:44 #topic Migrate Jenkins-on-Jenkins jobs onto jenkins.ci.cloudbees.com 18:28:51 rtyler: ping 18:28:54 but he's away 18:29:05 Why jenkins should be hosted under CB? 18:29:31 what we will do if cloudbees.com will be blocked? 18:29:34 The context is that we feel we are taking on too many services on our own than we can handle with our resources 18:29:59 it would reduce infra support efforts in general 18:30:10 So we offload services to other SaaS where we can. 18:30:28 IRC logger being one, datadog is another, MySQL is yet another. 18:31:13 KostyaSha: I'm sensitive that some people are concerned with us the project relying more on CB infra 18:31:51 But in many ways it's really no different from us getting database hosting from OSUOSL for Wiki&JIRA 18:31:52 kohsuke, then only CB will be able to support/count resources/etc 18:31:58 Oh no 18:32:08 This is a part of FOSS hosting of Jenkins 18:32:20 i'm here is 18:32:21 ish* 18:32:31 so why domain need to be changed then? 18:32:45 People will have to create accounts but people can have access 18:33:03 A significant infra part is being already hosted on CB infra (PR builders, etc.) 18:33:27 oleg-nenashev, and only CB can fix pr builder, right? 18:33:37 that constantly disappears 18:33:55 Actually, it's a topic for discussion 18:34:18 the primary problem is that we're underinvesting in terms of time to manage Jenkins ourselves 18:34:27 It's true that jenkins.ci.cloudbees.com uses some additional proprietary plugins 18:34:30 well, i expect to have jenkins infra on jenkins domain and some note that it sponsored by CloudBees 18:35:13 kohsuke, what plugins? can i replace PR builder with my FOSS variant if i will support hooks? 18:35:51 KostyaSha: yeah, I think that's fine 18:36:01 having parts of jenkins infra on different domains is not obvious for users imho 18:36:10 that's easy to fix with cnames KostyaSha 18:36:29 Logistically I'm not sure if it's that easy rtyler 18:36:40 I'm most interested in problems we might experience in terms of maintainership and ownership of jenkins if it's on enterprise jenkins 18:36:58 rtyler, https://issues.jenkins-ci.org/browse/INFRA-185 18:37:01 INFRA-185:disable old buildhive.cloudbees.com/job/jenkinsci PR builder (Reopened) https://issues.jenkins-ci.org/browse/INFRA-185 18:37:22 buildhive is not the same as enterprise jenkins 18:37:23 Created: 22/Oct/14 11:57 PM 18:37:46 kohsuke: is it possible to use our LDAP with enterprise jenkins, are we already doing that? I can't remember 18:37:50 We can disable those plugins if people feel use of that would act as a trap 18:38:18 No, I don't think it's possible to use LDAP 18:38:41 But SAML I believe we support, so maybe there's a way to make it work 18:38:55 rtyler: It should not be a blocker IMO. There're very few people accessing the infra CI 18:39:39 right 18:39:59 I want to make sure that we're providing the best service possible, and I think a sponsored host from CB will be the best means to approach it 18:40:10 I think sharing auth is a requirement 18:40:22 the FOSS plugins being used is probably just a good idea 18:41:19 kohsuke, rtyler can the whole existed server can be migrated to CB infra without migrating just only jobs? 18:41:26 Let me talk to the team to see if LDAP can be used through SAML 18:41:35 if this server uses proprietary plugins, then it will be separate question 18:42:14 KostyaSha: we'll have to copy jobs and tweak them, no problem. 18:42:43 what will be run on this server other? 18:42:58 ? 18:43:04 if jenkins decided to broke this server, will it affect CB? 18:43:16 #action kohsuke to check the feasibility of using ldap.jenkins-ci.org with jenkins.ci.cloudbees.com 18:43:36 I'm still not sure if I understand your question, KostyaSha 18:44:16 kohsuke: There may be dependencies on local resources, etc. The migration to an external CI provider will take much time, but IMO it's a right way. DEV@Cloud is much more preferable than Travis CI :) 18:44:54 Yes, we need to run a slave on cucumber to be able to continue running some infra tasks 18:45:39 what CB provides then? Existed jenkins and not just a VM? 18:46:11 A monitored & patched Jenkins instance 18:46:27 SaaS 18:46:29 patched as in "properly upgraded" 18:46:47 so jenkins is project wouldn't use it's own jenkins 18:46:49 *as 18:47:26 We will use Jenkins but we won't try to keep it up & running ourselves, yes. 18:48:22 Will be able to run jenkins infra if users donate enough money? 18:48:26 *will we 18:48:40 It’s not just about money. It’s about people’s time. 18:48:51 I have no idea how 8 servers can ate much money 18:49:35 we don't need money 18:49:39 for this anyways 18:49:52 “rtyler: the primary problem is that we're underinvesting in terms of time to manage Jenkins ourselves 18:49:52 [11:34am]” 18:49:53 kohsuke: is Enterprise Jenkins on LTS? 18:50:14 This is basically LTS + some plugins 18:50:31 is it kept up to date with LTS? 18:50:44 hare_brain, maillist get enough replies of persons that want help with infra 18:50:44 Generally, yes 18:50:58 Is there a way to get the output from the console and parse it then trigger an action based on the output? 18:51:21 I think overall I'm hearing the support for this move 18:51:34 no way 18:51:42 KostyaSha: what is your concern? 18:52:10 kohsuke, provide full state of jenkins infra for discussion, how many servers, how many services, what need to be supported 18:52:21 that's not what we're discussing here 18:52:46 we are discussing migration because current support people have no time and new persons not added 18:53:19 so yes, easy migrate jenkins somewhere else 18:54:08 Adding more people to infra / creating structure to make part-timer volunteers more effective in infra is something we are doing, but I think that's not mutually exclusive from reducing the burden we take on? 18:55:01 So that's why I'm asking if you have concerns in offloading J-on-J to jenkins.ci.cloudbees.com 18:55:14 Imho using latest jenkins LTS for J-o-J is good for jenkins as project - more testing, prove that it can works 18:55:37 allow -rc testing for ogondza for example 18:55:49 I disagree strongly with that actually 18:55:54 dog fooding is definitely great 18:55:58 that I don't disagree with 18:56:19 but affecting plugin developers, for example, by basically beta-testing on our core infrastructure, is pretty risky 18:56:35 rtyler: even lts rc? 18:56:35 rtyler, have you asked them? 18:56:39 and is not an acceptable substitution IMO for actual test automation and things like that 18:57:06 rtyler, i'm jenkins dev and i will be glad to have better tested LTS, i think all maintainers understand that it has benefits 18:57:08 KostyaSha: I hear about it every time update center generation slows or fails due to J-on-J instability 18:57:35 KostyaSha: I'm not saying we shouldn't be dogfodding or testing, I'm saying that running our core project operations on pre-release software is inherently risky 18:57:36 from an enterprise standpoint your build env should be STABLE, not bleeding edge. but that's my 2c worth 18:57:53 running LTS RCs however, is something I can be convinced of 18:57:57 sfisque, LTS != dev version 18:58:15 if LTS can't be stable with jenkins dev tasks, then it can't be stable for users 18:58:19 Mission-critical infrastructure should be launched on the most stable release even if it's a patched version from CB 18:59:13 anyway, I thing we are off topic here. +1 on simplifying infra 18:59:14 oleg-nenashev, then it a shame for project ;) 18:59:26 there's an assumption under here that I don't like, which is that by the mere fact taht we're running a pre-release version, we're somehow going to spot bugs before they affect users 18:59:51 rtyler, i think you don't know what is LTS, what kind of quality it have 19:00:07 We could leave J-o-J as a playground with stubbed versions of all jobs we use 19:00:31 The other parts of this is to relieve cucumber which is very congested 19:00:48 ogondza: it sounds like there's a supplemental requirement here for an integration test environment 19:01:07 so if we want to run Jenkins instance for dogfooding, we want it elsewhere. 19:01:55 We have very little people reporting back during the lts rc period 19:01:56 I suggest we run jenkins.ci.cloudbees.com for our primary CI, but we start to flesh out as well a better dogfooding and integration testing/staging environment for core 19:02:09 giving them a playground could help 19:02:38 i remember rtyler words that he hates jvm based tools, i saw 0 commits in jenkins code, i don't want to swear 19:02:42 rtyler: +1, and I assume you still want to find out if our LDAP can be used over there, right? 19:02:52 yes 19:02:52 so +1 for migration, no way 19:03:02 do what you can and want 19:03:10 KostyaSha: there are many ways to contribute to the project, a commit count is just one of them. 19:03:28 #action rtyler to write out some ideas on managing and providing a staging Jenkins infrastructure for developers 19:03:33 I need you to pay respect that a long time contributor like rtyler deserves 19:03:49 * rtyler shrugs 19:03:51 I'm sorry, but I really need to go 19:03:52 I'm not offended 19:04:00 do we have other topics to discuss? 19:04:03 I am offended 19:04:12 Yes, we have other topics 19:04:19 #action kohsuke to figure out what job migration from J-on-J looks like 19:04:40 the security bounties? 19:04:48 That and another agenda from KostyaSha 19:05:12 what's KostyaSha's item? 19:05:16 * rtyler is looking at the wiki 19:05:23 rtyler, from previous meeting 19:05:26 ah 19:05:28 Some technical question 19:05:39 Can we do that in the office hours next week, KostyaSha ? 19:05:44 I think it's a better avenue to do that 19:05:44 but danielbeck added additional item to my question :) 19:06:09 kohsuke, can i just ask you to look on PR and open issue? Probably you can comment in any free time? 19:06:27 Do you guys want to leave the meeting open or should I end it and push the rest to the next time? 19:06:38 kohsuke, as you wish 19:06:45 if you need go, then let's end 19:06:58 Let's do it next time. The next topic is from danielbeck and he isn't here. 19:07:04 #topic next meeting 19:07:21 #info the next meeting is 4/29 19:07:27 the same time as always 19:07:29 #endmeeting