Tuesday, 2017-11-28

*** jkilpatr has quit IRC00:36
*** jkilpatr has joined #zuul00:44
*** jkilpatr has quit IRC00:50
*** jkilpatr has joined #zuul01:02
openstackgerritIan Wienand proposed openstack-infra/zuul-jobs master: Move to dictionary list of projects zuul._projects (take 2)  https://review.openstack.org/51881501:09
*** jkilpatr has quit IRC01:09
*** jkilpatr has joined #zuul01:10
*** jkilpatr has quit IRC01:38
*** yolanda has quit IRC01:54
*** yolanda has joined #zuul02:18
*** yolanda has quit IRC02:24
*** yolanda has joined #zuul02:41
*** jaianshu has joined #zuul03:51
*** jaianshu_ has joined #zuul04:59
*** jaianshu has quit IRC04:59
*** threestrands has quit IRC05:10
*** threestrands has joined #zuul05:10
*** threestrands has quit IRC05:10
*** threestrands has joined #zuul05:10
*** threestrands has quit IRC05:12
*** threestrands has joined #zuul05:12
*** threestrands has quit IRC05:12
*** threestrands has joined #zuul05:12
openstackgerritTristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: mqtt: add basic reporter  https://review.openstack.org/51827906:27
*** nguyentrihai has quit IRC06:39
*** nguyentrihai has joined #zuul06:45
*** xinliang has quit IRC06:46
*** flepied_ has quit IRC06:52
*** flepied has joined #zuul06:54
*** xinliang has joined #zuul07:00
*** xinliang has quit IRC07:00
*** xinliang has joined #zuul07:00
*** threestrands has quit IRC07:04
*** hashar has joined #zuul07:42
*** flepied has quit IRC08:50
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Refactor provider config to driver module  https://review.openstack.org/48838408:56
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement a static driver for Nodepool  https://review.openstack.org/46862408:56
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement an OpenContainer driver  https://review.openstack.org/46875308:57
openstackgerritRui Chen proposed openstack-infra/nodepool feature/zuulv3: Fix nodepool alien-list issue  https://review.openstack.org/52249509:35
*** flepied has joined #zuul09:41
openstackgerritMerged openstack-infra/zuul-jobs master: Remove old python-sdist job  https://review.openstack.org/51392609:44
*** openstackgerrit has quit IRC09:48
*** electrofelix has joined #zuul09:50
*** bhavik1 has joined #zuul10:04
bhavik1help required.. I'm trying to setup zuulv3, mainly to work with github integration. Our hosts are in close network and that case github webhook will not reach to host IP address. any alternate way to achieve this? like, pull github events instead github webhook to POST payload?10:10
*** bhavik1 has quit IRC10:43
tristanCbeing able to ingest github events without using webhook might be something worthy to look at, it would let us run ci jobs without needing project owner to install a app or configure webhook10:57
tristanCa hypothetical mail driver would be able to do that by subscribing to the project activity :-)11:00
*** jkilpatr has joined #zuul11:06
*** flepied_ has joined #zuul11:21
*** flepied has quit IRC11:24
*** openstackgerrit has joined #zuul11:24
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Refactor provider config to driver module  https://review.openstack.org/48838411:24
*** jkilpatr has quit IRC11:27
*** jkilpatr has joined #zuul11:38
*** jkilpatr has quit IRC12:06
*** jkilpatr has joined #zuul12:07
*** jaianshu__ has joined #zuul12:25
*** jaianshu__ has quit IRC12:25
*** jaianshu_ has quit IRC12:28
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement a static driver for Nodepool  https://review.openstack.org/46862412:35
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement an OpenContainer driver  https://review.openstack.org/46875312:36
sshnaidmDo we use storyboard for zuulv3 bugs/issues/suggestions?12:59
*** bhavik1 has joined #zuul13:03
*** yolanda has quit IRC13:16
*** yolanda has joined #zuul13:21
tobiashsshnaidm: jeblair created the roadmap in storyboard: https://storyboard.openstack.org/#!/board/5313:23
sshnaidmyeah, but I'm asking for example, if I want to suggest ansible tags support in zuul - where should I submit this? jeblair ?13:25
sshnaidmwe had some discussion yesterday, I don't want it to be lost in current tasks..13:26
tobiashlet's ask jeblair how to proceed there13:26
*** bhavik1 has quit IRC13:33
*** hashar has quit IRC13:46
*** hashar has joined #zuul13:47
*** yolanda has quit IRC14:21
*** dkranz has joined #zuul14:21
*** yolanda has joined #zuul14:35
jeblairsshnaidm: i suggest creating a story in storyboard15:19
sshnaidmjeblair, great, in which project? openstack-infra/zuul  ?15:23
jeblairsshnaidm: yep15:24
*** hashar is now known as hasharAway15:25
*** dkranz has quit IRC15:26
*** dkranz has joined #zuul15:27
*** jasondotstar has quit IRC15:29
*** jasondotstar has joined #zuul15:44
*** haint has joined #zuul16:01
*** nguyentrihai has quit IRC16:05
pabelangerre: zuul-dashboard. Have we discussed maybe making a new project for it on openstack-infra, and moving it (dashboard) and zuul status into? Mostly thinking it would be nicer to organize it into 2 repos16:11
dmsimardjeblair: should https://etherpad.openstack.org/p/downstream-zuul-jobs-issues be part of the 3.0 roadmap ?16:36
dmsimardjeblair: as in, make sure zuul-jobs can be consumed outside of openstack16:37
dmsimardHaven't yet had the opportunity to test everything.. would we be interested in some form of third party CI on zuul-jobs ?16:38
jeblairdmsimard: i don't think anything there impacts the zuul codebase, so i don't think they are release blockers.  i'd love third-party ci on zuul-jobs.  :)16:40
dmsimardjeblair: zuul-jobs isn't considered part of the zuul code base ?16:40
dmsimardnot challenging the statement, genuine question16:41
jeblairdmsimard: well, i literally meant the code in 'openstack-infra/zuul'16:41
jeblairdmsimard: we have no plans to 'release' the content in zuul-jobs.  it's meant to be continuously deployed16:41
dmsimardhm, I wonder to what extent keeping the two "out of sync" could be problematic16:42
dmsimardbad hypothetical example because I can't think of anything else, but for example the _projects dict re-work could not be released in zuul 3.0 tag (but it's in trunk?) and the refactor is in zuul-jobs16:43
jeblairdmsimard: once we release 3.0, we're going to have a pretty generous deprecation cycle, so i'm not anticipating much more complication than supporting users in general16:44
jeblairdmsimard: well, yeah, that's all work we're going to complete before 3.0 because we *don't* want to maintain backwards compat16:44
dmsimardwe'll need to take that deprecation cycle into account in zuul-jobs though16:44
dmsimardlike if we add a new feature in zuul trunk, and we leverage it in zuul jobs, people might not be running trunk16:45
jeblairdmsimard: yes16:45
dmsimardok, we'll need to make that clear to core reviewers16:45
jeblairyep16:45
jeblairwe're also likely to release zuul much more often after 3.016:45
dmsimardI hear you on (not) keeping backwards compat and breaking everything you can now16:46
dmsimardpretty much the entire purpose of ara 1.0 :p16:46
jeblair(zuul used to release quite frequently)16:46
dmsimardyeah I saw mentions of 3.1 already :)16:46
openstackgerritPaul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command_socket setting to executor section  https://review.openstack.org/52346516:52
openstackgerritPaul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command socket support to zuul-scheduler  https://review.openstack.org/52346616:52
*** nhicher has joined #zuul16:58
mordredelectrofelix: heya! so - I realized something right before the holidays about your zuulv3/jenkins situation - about some ways you might be able to experiment with integration between the two without needing new plugins - but it sort of depends on what your setup actually looks like17:02
jeblairdmsimard: added a note to the last downstream issue17:02
mordredelectrofelix: you said your jenkins has static nodes ... are they individual known static nodes that have a 1:1 relationship with jobs? or are they sets of static nodes that share a label like 'centos-x86' and jenkins will run a given job on one of them but you don't necessarily know which one?17:04
tobiashjeblair: I think it might be possible to use plain git there and handle incremental and clean sync within a single role17:09
tobiashThat's what I meant with the last downstream issue17:09
tobiashHopefully I'll have time soon to try that out17:10
jeblairtobiash: ah cool, yeah that would be an improvement :)17:12
jeblairand would reduce the risk of prepare-workspace bitrotting17:13
tobiashI'd like to see that entirely within zuul-jobs17:13
*** flepied_ has quit IRC17:17
jeblairtobiash: the current split is not an accident -- what's in project-config is an openstackism -- porting it over may require thought17:22
tobiashjeblair: I have to look closer on that next week when I have my new deployment ready such that I can try this out17:25
tobiashBut the use case itself doesn't sound so much openstack specific17:27
pabelangerjeblair: did you have any more thoughts on shared ansible_host in inventory (521324)?17:27
jeblairpabelanger: i'd like mordred to weigh in on that17:32
mordredpabelanger: sorry, it's open in my review queue, I'll respond today17:37
mordredtobiash, jeblair: the "there may be cached copies of repos on the node already, so do rsync things"?17:38
*** jasondotstar has quit IRC17:42
tobiashmordred: almost, if there are cached copies of repos on the node, do git instead of rsync is the idea17:43
tobiashjeblair: I just saw that the most important part of this is already in zuul-jobs17:44
jeblairmordred, tobiash: yeah.  i think the assumptions in that role are 1) repos would be placed in /opt/git;  2) you can clone them from https://{{canonical_name}}17:44
tobiashjeblair: yes, that's the part which is in project-config17:44
tobiashwhich might be configurable17:44
jeblairyep17:45
tobiashstep 2 could probably also be done by a git init17:45
tobiashas the incremental git sync would do all necessary steps17:45
tobiashor fall back to rsync in step 217:46
jeblairtobiash: the clone is to handle repos that did not exist when the image was created17:47
jeblairtobiash: oh i see what you mean17:47
jeblairtobiash: i agree :)17:47
*** jasondotstar has joined #zuul17:48
jeblairtobiash: so yeah, configurable location + git init probably would make that generic enough for zuul-jobs17:48
tobiashjeblair: you just need a git repo, the incremental push would handle all stuff17:48
tobiashmaybe as an optimization fall back to rsync if it's not there, which could possibly faster than git init + push (but I'm not so sure about that)17:49
tobiashgit push is probably more efficient in terms of streaming the data17:49
*** dkranz has quit IRC17:50
electrofelixmordred: it's the second one, set of nodes that have a label applied and don't know which slave will get the job beforehand17:52
tobiashwhat's missing in the mirror-workspace-git-repos role would be deleting all branches which we haven't pushed17:53
tobiashnot sure if that's easily possible with git push17:53
tobiashah cool, push also knows --prune17:54
tobiashand --mirror also does that17:56
tobiashI thought that would be additive17:56
tobiashso even that is already handled17:56
*** sshnaidm is now known as sshnaidm|off17:59
mordredelectrofelix: ok. that's the slightly more complex version and might still require the nodepool plugin - but it could replace the gearman plugin so maybe it's a wash in terms of convincing people to install a plugin?18:02
mordredtobiash: cool! so yeah - I think it would be neat to make that generally usable / configurable. I'd imagine that setting zuul_git_repo_cache_location or whatever we call it in a site-variables.yaml file would be the cleanest way for a zuul operator to specify one ...18:04
electrofelixmordred: Is there a reason to remove the Gearman plugin there? Or how would the replacement plugin work with multiple Jenkins masters? How will zuul know which master should be the one to execute the jobs?18:07
openstackgerritPaul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command_socket setting to executor section  https://review.openstack.org/52346518:16
openstackgerritPaul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command socket support to zuul-scheduler  https://review.openstack.org/52346618:16
* rcarrillocruz waves18:25
rcarrillocruzso, i was thinking, in our non Zuul CI (yeah, have another zuulv3 in testing, but our current one is a bare nodepool + running cronjobs) we use the groups created by nodepool from the openstack metadata, meaning they come from openstack inventory18:27
rcarrillocruzwould it be useful to people if i write a nodepool ansible inventory plugin?18:27
rcarrillocruzlike, in the end, we jsut care nodepool labels can be sshable, end user playbooks or test runs should not care they come from openstack or not18:27
rcarrillocruzthoughts?18:27
*** flepied_ has joined #zuul18:27
clarkbrcarrillocruz: at least for the openstack case si that any different than the existing openstack inventory plugin thing?18:28
jlkwell..18:28
jlkfrom nodepool we'd want a few things18:28
jlklike connection plugin, user, etc.18:28
jlksince Nodepool in the future will be more than just OpenStack18:29
rcarrillocruzyeah, thinking forward for the ansible driver for example in nodepool18:29
rcarrillocruzin non zuul CIs18:29
rcarrillocruzif we had that inventory18:29
clarkbgotcha so you'd only be talking to nodepool and would ignore the openstack metadata from that point forward (or possibly supplement it and other cloud info)18:29
rcarrillocruzproviding nodepool will provide connection, port, user, etc, as jlk  says, the inventory would just give that18:29
rcarrillocruzclarkb: right18:29
mordredrcarrillocruz: I think a nodepool inventory for ansible would be a fine idea for that use case - although I do think that writing out static inventories directly from nodepool metadata inside of zuul is still the right way to go zuul-side18:32
rcarrillocruzyah18:32
mordredrcarrillocruz: I've also been on the fence as to whether or not we should have the openstack driver supplement requested groups with the groups the ansible inventory plugin normally creates ... I can't decide if that would be a good or a bad idea :)18:33
rcarrillocruzyeah, so ...along those lines, nodepool creates images groups, but that's something we do get for free anyways by the openstack inventory18:34
rcarrillocruzwhich btw , gave me a bit of headache when i setup the just-nodepool, as having labels named the same as images caused i could not reference a label group and be sure those UUIDs were 'just' the labels18:37
rcarrillocruzi ended up appending -labels to labels on my nodepool.yml file18:37
rcarrillocruze.g. label: ubuntu-xenial18:40
rcarrillocruzimage: ubuntu-xenial18:40
rcarrillocruzas nodepool creates groups for both labels and images18:40
rcarrillocruzthose are merged18:40
rcarrillocruzhaving all nodes being labeled ubuntu-xenial PLUS all nodes using image ubuntu-xenial18:40
rcarrillocruzhmm18:43
rcarrillocruzhttps://review.openstack.org/#/c/501976/8/zuul/executor/server.py18:43
rcarrillocruzweren't we saying the other day to be wary of doing localhost things on executor?18:44
rcarrillocruzperhaps a check there in case is connection local and bail out ?18:44
*** flepied_ has quit IRC18:44
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Remove bindep_profile from unittests/pre.yaml  https://review.openstack.org/52350118:53
clarkbrcarrillocruz: I think we patch out connection local to error already, but catching it at a higher level and providing a nice error mesage is likely better user experience18:54
* SpamapS is playing with making a GCE nodepool driver later this week btw19:09
SpamapSsince I just got an account on GCE to play with19:09
SpamapS(and an AWS.. but... who wants to play with AWS?)19:09
jlklol.19:09
jlkSpamapS: GCE as in VMs?19:09
openstackgerritJeremy Stanley proposed openstack-infra/zuul-jobs master: DO NOT MERGE: testing the bindep_profile fallback  https://review.openstack.org/52350619:13
SpamapSjlk: aye19:17
SpamapSjlk: though I may push it all the way to k8s if I can get enough time.19:17
*** flepied_ has joined #zuul19:18
jlkIt looked like the one submitted got a good distance of the way there, even if we disagree on the connection method19:18
jlkthough it does punt on the whole "make nightly images" bits doesn't it? Requires existing images to make use of.19:19
jeblairfyi third-party ci of zuul-jobs is being discussed in the openstack-infra meeting now in #openstack-meeting19:21
*** flepied_ has quit IRC19:22
*** electrofelix has quit IRC19:25
rcarrillocruzOh19:26
rcarrillocruzThx19:26
rcarrillocruzInterested on that19:26
openstackgerritMerged openstack-infra/zuul-jobs master: Remove bindep_profile from unittests/pre.yaml  https://review.openstack.org/52350119:54
*** dkranz has joined #zuul20:02
*** flepied has joined #zuul20:11
*** flepied has quit IRC20:15
openstackgerritMerged openstack-infra/nodepool feature/zuulv3: Fix broken use of pre-existing cloud images  https://review.openstack.org/49805020:16
*** flepied has joined #zuul21:23
*** openstack has joined #zuul21:46
*** ChanServ sets mode: +o openstack21:46
*** dkranz has quit IRC22:00
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Combine branch templates and pipeline branch matchers  https://review.openstack.org/52354422:07
*** sboyron has joined #zuul22:12
jeblairif folks have a moment to look at that ^ i'd appreciate it.  i think it fixes an important unexpected behavior, and would like to merge it soon.22:35
jlkreading22:38
mordredjeblair: opened up for reading22:48
*** sboyron has quit IRC23:00
jeblairalso there's some advanced ansible/jinja in https://review.openstack.org/518815 that looks right to me but i'd love another eye on that.  then we can finish up the projects list -> dict conversion.23:15
dmsimardjeblair: added myself to 518815, I need to go run some errands, I'll try to look at it after23:36
mordredjeblair: +2 on https://review.openstack.org/#/c/523544  - I didn't +A in case you wanted other people to review it23:45
*** jasondotstar has quit IRC23:49

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!