*** jkilpatr has quit IRC | 00:36 | |
*** jkilpatr has joined #zuul | 00:44 | |
*** jkilpatr has quit IRC | 00:50 | |
*** jkilpatr has joined #zuul | 01:02 | |
openstackgerrit | Ian Wienand proposed openstack-infra/zuul-jobs master: Move to dictionary list of projects zuul._projects (take 2) https://review.openstack.org/518815 | 01:09 |
---|---|---|
*** jkilpatr has quit IRC | 01:09 | |
*** jkilpatr has joined #zuul | 01:10 | |
*** jkilpatr has quit IRC | 01:38 | |
*** yolanda has quit IRC | 01:54 | |
*** yolanda has joined #zuul | 02:18 | |
*** yolanda has quit IRC | 02:24 | |
*** yolanda has joined #zuul | 02:41 | |
*** jaianshu has joined #zuul | 03:51 | |
*** jaianshu_ has joined #zuul | 04:59 | |
*** jaianshu has quit IRC | 04:59 | |
*** threestrands has quit IRC | 05:10 | |
*** threestrands has joined #zuul | 05:10 | |
*** threestrands has quit IRC | 05:10 | |
*** threestrands has joined #zuul | 05:10 | |
*** threestrands has quit IRC | 05:12 | |
*** threestrands has joined #zuul | 05:12 | |
*** threestrands has quit IRC | 05:12 | |
*** threestrands has joined #zuul | 05:12 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: mqtt: add basic reporter https://review.openstack.org/518279 | 06:27 |
*** nguyentrihai has quit IRC | 06:39 | |
*** nguyentrihai has joined #zuul | 06:45 | |
*** xinliang has quit IRC | 06:46 | |
*** flepied_ has quit IRC | 06:52 | |
*** flepied has joined #zuul | 06:54 | |
*** xinliang has joined #zuul | 07:00 | |
*** xinliang has quit IRC | 07:00 | |
*** xinliang has joined #zuul | 07:00 | |
*** threestrands has quit IRC | 07:04 | |
*** hashar has joined #zuul | 07:42 | |
*** flepied has quit IRC | 08:50 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Refactor provider config to driver module https://review.openstack.org/488384 | 08:56 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement a static driver for Nodepool https://review.openstack.org/468624 | 08:56 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement an OpenContainer driver https://review.openstack.org/468753 | 08:57 |
openstackgerrit | Rui Chen proposed openstack-infra/nodepool feature/zuulv3: Fix nodepool alien-list issue https://review.openstack.org/522495 | 09:35 |
*** flepied has joined #zuul | 09:41 | |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Remove old python-sdist job https://review.openstack.org/513926 | 09:44 |
*** openstackgerrit has quit IRC | 09:48 | |
*** electrofelix has joined #zuul | 09:50 | |
*** bhavik1 has joined #zuul | 10:04 | |
bhavik1 | help 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 IRC | 10:43 | |
tristanC | being 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 webhook | 10:57 |
tristanC | a hypothetical mail driver would be able to do that by subscribing to the project activity :-) | 11:00 |
*** jkilpatr has joined #zuul | 11:06 | |
*** flepied_ has joined #zuul | 11:21 | |
*** flepied has quit IRC | 11:24 | |
*** openstackgerrit has joined #zuul | 11:24 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Refactor provider config to driver module https://review.openstack.org/488384 | 11:24 |
*** jkilpatr has quit IRC | 11:27 | |
*** jkilpatr has joined #zuul | 11:38 | |
*** jkilpatr has quit IRC | 12:06 | |
*** jkilpatr has joined #zuul | 12:07 | |
*** jaianshu__ has joined #zuul | 12:25 | |
*** jaianshu__ has quit IRC | 12:25 | |
*** jaianshu_ has quit IRC | 12:28 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement a static driver for Nodepool https://review.openstack.org/468624 | 12:35 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement an OpenContainer driver https://review.openstack.org/468753 | 12:36 |
sshnaidm | Do we use storyboard for zuulv3 bugs/issues/suggestions? | 12:59 |
*** bhavik1 has joined #zuul | 13:03 | |
*** yolanda has quit IRC | 13:16 | |
*** yolanda has joined #zuul | 13:21 | |
tobiash | sshnaidm: jeblair created the roadmap in storyboard: https://storyboard.openstack.org/#!/board/53 | 13:23 |
sshnaidm | yeah, but I'm asking for example, if I want to suggest ansible tags support in zuul - where should I submit this? jeblair ? | 13:25 |
sshnaidm | we had some discussion yesterday, I don't want it to be lost in current tasks.. | 13:26 |
tobiash | let's ask jeblair how to proceed there | 13:26 |
*** bhavik1 has quit IRC | 13:33 | |
*** hashar has quit IRC | 13:46 | |
*** hashar has joined #zuul | 13:47 | |
*** yolanda has quit IRC | 14:21 | |
*** dkranz has joined #zuul | 14:21 | |
*** yolanda has joined #zuul | 14:35 | |
jeblair | sshnaidm: i suggest creating a story in storyboard | 15:19 |
sshnaidm | jeblair, great, in which project? openstack-infra/zuul ? | 15:23 |
jeblair | sshnaidm: yep | 15:24 |
*** hashar is now known as hasharAway | 15:25 | |
*** dkranz has quit IRC | 15:26 | |
*** dkranz has joined #zuul | 15:27 | |
*** jasondotstar has quit IRC | 15:29 | |
*** jasondotstar has joined #zuul | 15:44 | |
*** haint has joined #zuul | 16:01 | |
*** nguyentrihai has quit IRC | 16:05 | |
pabelanger | re: 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 repos | 16:11 |
dmsimard | jeblair: should https://etherpad.openstack.org/p/downstream-zuul-jobs-issues be part of the 3.0 roadmap ? | 16:36 |
dmsimard | jeblair: as in, make sure zuul-jobs can be consumed outside of openstack | 16:37 |
dmsimard | Haven't yet had the opportunity to test everything.. would we be interested in some form of third party CI on zuul-jobs ? | 16:38 |
jeblair | dmsimard: 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 |
dmsimard | jeblair: zuul-jobs isn't considered part of the zuul code base ? | 16:40 |
dmsimard | not challenging the statement, genuine question | 16:41 |
jeblair | dmsimard: well, i literally meant the code in 'openstack-infra/zuul' | 16:41 |
jeblair | dmsimard: we have no plans to 'release' the content in zuul-jobs. it's meant to be continuously deployed | 16:41 |
dmsimard | hm, I wonder to what extent keeping the two "out of sync" could be problematic | 16:42 |
dmsimard | bad 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-jobs | 16:43 |
jeblair | dmsimard: 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 general | 16:44 |
jeblair | dmsimard: well, yeah, that's all work we're going to complete before 3.0 because we *don't* want to maintain backwards compat | 16:44 |
dmsimard | we'll need to take that deprecation cycle into account in zuul-jobs though | 16:44 |
dmsimard | like if we add a new feature in zuul trunk, and we leverage it in zuul jobs, people might not be running trunk | 16:45 |
jeblair | dmsimard: yes | 16:45 |
dmsimard | ok, we'll need to make that clear to core reviewers | 16:45 |
jeblair | yep | 16:45 |
jeblair | we're also likely to release zuul much more often after 3.0 | 16:45 |
dmsimard | I hear you on (not) keeping backwards compat and breaking everything you can now | 16:46 |
dmsimard | pretty much the entire purpose of ara 1.0 :p | 16:46 |
jeblair | (zuul used to release quite frequently) | 16:46 |
dmsimard | yeah I saw mentions of 3.1 already :) | 16:46 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command_socket setting to executor section https://review.openstack.org/523465 | 16:52 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command socket support to zuul-scheduler https://review.openstack.org/523466 | 16:52 |
*** nhicher has joined #zuul | 16:58 | |
mordred | electrofelix: 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 like | 17:02 |
jeblair | dmsimard: added a note to the last downstream issue | 17:02 |
mordred | electrofelix: 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 |
tobiash | jeblair: I think it might be possible to use plain git there and handle incremental and clean sync within a single role | 17:09 |
tobiash | That's what I meant with the last downstream issue | 17:09 |
tobiash | Hopefully I'll have time soon to try that out | 17:10 |
jeblair | tobiash: ah cool, yeah that would be an improvement :) | 17:12 |
jeblair | and would reduce the risk of prepare-workspace bitrotting | 17:13 |
tobiash | I'd like to see that entirely within zuul-jobs | 17:13 |
*** flepied_ has quit IRC | 17:17 | |
jeblair | tobiash: the current split is not an accident -- what's in project-config is an openstackism -- porting it over may require thought | 17:22 |
tobiash | jeblair: I have to look closer on that next week when I have my new deployment ready such that I can try this out | 17:25 |
tobiash | But the use case itself doesn't sound so much openstack specific | 17:27 |
pabelanger | jeblair: did you have any more thoughts on shared ansible_host in inventory (521324)? | 17:27 |
jeblair | pabelanger: i'd like mordred to weigh in on that | 17:32 |
mordred | pabelanger: sorry, it's open in my review queue, I'll respond today | 17:37 |
mordred | tobiash, jeblair: the "there may be cached copies of repos on the node already, so do rsync things"? | 17:38 |
*** jasondotstar has quit IRC | 17:42 | |
tobiash | mordred: almost, if there are cached copies of repos on the node, do git instead of rsync is the idea | 17:43 |
tobiash | jeblair: I just saw that the most important part of this is already in zuul-jobs | 17:44 |
jeblair | mordred, 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 |
tobiash | jeblair: yes, that's the part which is in project-config | 17:44 |
tobiash | which might be configurable | 17:44 |
jeblair | yep | 17:45 |
tobiash | step 2 could probably also be done by a git init | 17:45 |
tobiash | as the incremental git sync would do all necessary steps | 17:45 |
tobiash | or fall back to rsync in step 2 | 17:46 |
jeblair | tobiash: the clone is to handle repos that did not exist when the image was created | 17:47 |
jeblair | tobiash: oh i see what you mean | 17:47 |
jeblair | tobiash: i agree :) | 17:47 |
*** jasondotstar has joined #zuul | 17:48 | |
jeblair | tobiash: so yeah, configurable location + git init probably would make that generic enough for zuul-jobs | 17:48 |
tobiash | jeblair: you just need a git repo, the incremental push would handle all stuff | 17:48 |
tobiash | maybe 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 |
tobiash | git push is probably more efficient in terms of streaming the data | 17:49 |
*** dkranz has quit IRC | 17:50 | |
electrofelix | mordred: it's the second one, set of nodes that have a label applied and don't know which slave will get the job beforehand | 17:52 |
tobiash | what's missing in the mirror-workspace-git-repos role would be deleting all branches which we haven't pushed | 17:53 |
tobiash | not sure if that's easily possible with git push | 17:53 |
tobiash | ah cool, push also knows --prune | 17:54 |
tobiash | and --mirror also does that | 17:56 |
tobiash | I thought that would be additive | 17:56 |
tobiash | so even that is already handled | 17:56 |
*** sshnaidm is now known as sshnaidm|off | 17:59 | |
mordred | electrofelix: 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 |
mordred | tobiash: 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 |
electrofelix | mordred: 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 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command_socket setting to executor section https://review.openstack.org/523465 | 18:16 |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: Add command socket support to zuul-scheduler https://review.openstack.org/523466 | 18:16 |
* rcarrillocruz waves | 18:25 | |
rcarrillocruz | so, 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 inventory | 18:27 |
rcarrillocruz | would it be useful to people if i write a nodepool ansible inventory plugin? | 18:27 |
rcarrillocruz | like, 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 not | 18:27 |
rcarrillocruz | thoughts? | 18:27 |
*** flepied_ has joined #zuul | 18:27 | |
clarkb | rcarrillocruz: at least for the openstack case si that any different than the existing openstack inventory plugin thing? | 18:28 |
jlk | well.. | 18:28 |
jlk | from nodepool we'd want a few things | 18:28 |
jlk | like connection plugin, user, etc. | 18:28 |
jlk | since Nodepool in the future will be more than just OpenStack | 18:29 |
rcarrillocruz | yeah, thinking forward for the ansible driver for example in nodepool | 18:29 |
rcarrillocruz | in non zuul CIs | 18:29 |
rcarrillocruz | if we had that inventory | 18:29 |
clarkb | gotcha 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 |
rcarrillocruz | providing nodepool will provide connection, port, user, etc, as jlk says, the inventory would just give that | 18:29 |
rcarrillocruz | clarkb: right | 18:29 |
mordred | rcarrillocruz: 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-side | 18:32 |
rcarrillocruz | yah | 18:32 |
mordred | rcarrillocruz: 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 |
rcarrillocruz | yeah, so ...along those lines, nodepool creates images groups, but that's something we do get for free anyways by the openstack inventory | 18:34 |
rcarrillocruz | which 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 labels | 18:37 |
rcarrillocruz | i ended up appending -labels to labels on my nodepool.yml file | 18:37 |
rcarrillocruz | e.g. label: ubuntu-xenial | 18:40 |
rcarrillocruz | image: ubuntu-xenial | 18:40 |
rcarrillocruz | as nodepool creates groups for both labels and images | 18:40 |
rcarrillocruz | those are merged | 18:40 |
rcarrillocruz | having all nodes being labeled ubuntu-xenial PLUS all nodes using image ubuntu-xenial | 18:40 |
rcarrillocruz | hmm | 18:43 |
rcarrillocruz | https://review.openstack.org/#/c/501976/8/zuul/executor/server.py | 18:43 |
rcarrillocruz | weren't we saying the other day to be wary of doing localhost things on executor? | 18:44 |
rcarrillocruz | perhaps a check there in case is connection local and bail out ? | 18:44 |
*** flepied_ has quit IRC | 18:44 | |
openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Remove bindep_profile from unittests/pre.yaml https://review.openstack.org/523501 | 18:53 |
clarkb | rcarrillocruz: 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 experience | 18:54 |
* SpamapS is playing with making a GCE nodepool driver later this week btw | 19:09 | |
SpamapS | since I just got an account on GCE to play with | 19:09 |
SpamapS | (and an AWS.. but... who wants to play with AWS?) | 19:09 |
jlk | lol. | 19:09 |
jlk | SpamapS: GCE as in VMs? | 19:09 |
openstackgerrit | Jeremy Stanley proposed openstack-infra/zuul-jobs master: DO NOT MERGE: testing the bindep_profile fallback https://review.openstack.org/523506 | 19:13 |
SpamapS | jlk: aye | 19:17 |
SpamapS | jlk: though I may push it all the way to k8s if I can get enough time. | 19:17 |
*** flepied_ has joined #zuul | 19:18 | |
jlk | It looked like the one submitted got a good distance of the way there, even if we disagree on the connection method | 19:18 |
jlk | though it does punt on the whole "make nightly images" bits doesn't it? Requires existing images to make use of. | 19:19 |
jeblair | fyi third-party ci of zuul-jobs is being discussed in the openstack-infra meeting now in #openstack-meeting | 19:21 |
*** flepied_ has quit IRC | 19:22 | |
*** electrofelix has quit IRC | 19:25 | |
rcarrillocruz | Oh | 19:26 |
rcarrillocruz | Thx | 19:26 |
rcarrillocruz | Interested on that | 19:26 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Remove bindep_profile from unittests/pre.yaml https://review.openstack.org/523501 | 19:54 |
*** dkranz has joined #zuul | 20:02 | |
*** flepied has joined #zuul | 20:11 | |
*** flepied has quit IRC | 20:15 | |
openstackgerrit | Merged openstack-infra/nodepool feature/zuulv3: Fix broken use of pre-existing cloud images https://review.openstack.org/498050 | 20:16 |
*** flepied has joined #zuul | 21:23 | |
*** openstack has joined #zuul | 21:46 | |
*** ChanServ sets mode: +o openstack | 21:46 | |
*** dkranz has quit IRC | 22:00 | |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Combine branch templates and pipeline branch matchers https://review.openstack.org/523544 | 22:07 |
*** sboyron has joined #zuul | 22:12 | |
jeblair | if 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 |
jlk | reading | 22:38 |
mordred | jeblair: opened up for reading | 22:48 |
*** sboyron has quit IRC | 23:00 | |
jeblair | also 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 |
dmsimard | jeblair: added myself to 518815, I need to go run some errands, I'll try to look at it after | 23:36 |
mordred | jeblair: +2 on https://review.openstack.org/#/c/523544 - I didn't +A in case you wanted other people to review it | 23:45 |
*** jasondotstar has quit IRC | 23:49 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!