xinliang | Hi, do anybody know how jenkins pass job parameters to slave node? My issue is that I see the jenkins gearman plugin log has received ZUU_** job parameters, but in the slave node these parameters are empty. | 01:17 |
---|---|---|
xinliang | Any clues or thoughts on address this issue? | 01:18 |
clarkb | xinliang: yes there was a security issue so they are not passed by default | 01:21 |
clarkb | you can whitelist them or the gearman plugin iirc | 01:21 |
clarkb | I'm not sure how to do that as it happened after we stopped using jenkins | 01:21 |
xinliang | clarkb: Any reason you stopp using jenkins? | 01:24 |
xinliang | clarkb: I just at the begining of settin up third-party CI. Shall I stop using jenkins too? | 01:25 |
xinliang | I found current job definition in project-config are still jenkins job | 01:27 |
clarkb | xinliang: no people should continue using jrnkins until zuulv3 is ready | 01:36 |
clarkb | xinliang: I thought the third party docs have info on how to whitelist the env vars in jenkins | 01:36 |
xinliang | clarkb: Then I will stop using jenkins after zuulv3 is ready. | 01:40 |
xinliang | clarkb: I can't find info about how to whitelist the env vars in jenkins in third party docs. | 01:40 |
clarkb | xinliang: https://wiki.jenkins.io/plugins/servlet/mobile?contentId=98402886#content/view/98402886 has details on how to fix the parameters | 01:53 |
xinliang | clarkb: thanks :) | 02:17 |
openstackgerrit | Jamie Lennox proposed openstack-infra/zuul feature/zuulv3: Cleanup on ssh-agent failure https://review.openstack.org/481344 | 03:59 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: Add support for zuul.d configuration split https://review.openstack.org/473764 | 04:59 |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: Add support for zuul.d configuration split https://review.openstack.org/473764 | 05:13 |
*** isaacb has joined #zuul | 06:22 | |
*** isaacb has quit IRC | 07:00 | |
*** harlowja has quit IRC | 07:11 | |
openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Add job dependencies to status.json https://review.openstack.org/482061 | 09:03 |
*** isaacb has joined #zuul | 09:46 | |
*** isaacb has quit IRC | 10:41 | |
*** dkranz has quit IRC | 10:52 | |
*** xinliang has quit IRC | 10:53 | |
*** jkilpatr has joined #zuul | 11:01 | |
*** xinliang has joined #zuul | 11:05 | |
*** isaacb has joined #zuul | 11:43 | |
*** dkranz has joined #zuul | 11:48 | |
*** jkilpatr has quit IRC | 11:57 | |
*** jkilpatr has joined #zuul | 12:29 | |
openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Add web-based console log streaming https://review.openstack.org/463353 | 13:07 |
Shrews | ohai #zuul | 13:08 |
rcarrillocruz | Shrews: does ^ that mean we will be able to see job progress without telnet on console? | 13:11 |
rcarrillocruz | also ohai! | 13:12 |
rcarrillocruz | if so, wootz! | 13:12 |
Shrews | rcarrillocruz: we've had finger access for a few weeks now. that ^^^ gives us a web option without needing to know the executor to finger | 13:12 |
rcarrillocruz | will there be a clickable link from Zuul dashboard? | 13:13 |
Shrews | rcarrillocruz: if someone adds one :) | 13:13 |
rcarrillocruz | :D | 13:13 |
Shrews | rcarrillocruz: https://review.openstack.org/#/c/481599/ | 13:13 |
rcarrillocruz | geez, keep on going the goodness folks | 13:14 |
tobiash | Shrews: where this needs currently to be patched for every deployment | 13:22 |
tobiash | Shrews: I'm open for suggestions how to solve this better | 13:22 |
Shrews | tobiash: eh? sorry, i don't understand the question (still injecting coffee) | 13:23 |
tobiash | Shrews: sorry, regarding the link you just sent to rcarrillocruz ;) | 13:23 |
tobiash | Shrews: maybe it might make sense to include this into zuul-web so the websocket uri could be generated with knowlege of the zuul-web config | 13:24 |
Shrews | oh | 13:24 |
tobiash | Shrews: (there is a to be replaced url currently in the static html file) | 13:24 |
Shrews | tobiash: i think, based on mordred's #-infra email, that zuul-web will eventually be the single answer to the http interface for all the things | 13:28 |
tobiash | Shrews: then that would fit into the picture | 13:29 |
tobiash | Shrews: btw, good job, in my deployment the web based log streaming works great :) | 13:29 |
Shrews | awesome! i feel better about the unit test now | 13:30 |
*** jkilpatr has quit IRC | 14:06 | |
mordred | Shrews: yes! (also welcome back) | 14:22 |
*** isaacb_ has joined #zuul | 14:22 | |
*** isaacb has quit IRC | 14:24 | |
*** isaacb_ has quit IRC | 14:26 | |
jeblair | Shrews: welcome back! | 14:26 |
Shrews | all of the things are solved now, and we can deploy zuulv3 to production, right? | 14:27 |
Shrews | (if not, perhaps i will continue my vacation) | 14:27 |
jeblair | mordred: your work is 481817--481944 + 482119, right? | 14:27 |
*** isaacb has joined #zuul | 14:28 | |
jeblair | Shrews: then let's go with "yes" :) | 14:28 |
mordred | jeblair: yes - I made a topic even | 14:28 |
mordred | jeblair: zuul-base-jobs | 14:28 |
jeblair | mordred: cool, thx | 14:29 |
mordred | tobiash, Shrews: and as jeblair said - "yes" - I need to write something to the list- but I'm sort of hoping we can get tristanC's web dashboard landed too, and start to have web pages for changes and jobs and whatnot that can show stremaing logs or links to static logs as makes sense ... | 14:30 |
jeblair | mordred: we have a status page that shows links to streaming logs or static logs as makes sense....? | 14:31 |
mordred | I think we need an answer for what the config looks like for people not running the sql reporter so that zuul can serve the tobiash html for log streaming and the link to that can be shown in the status page | 14:31 |
openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Add web-based console log streaming https://review.openstack.org/463353 | 14:32 |
mordred | jeblair: yup! we do indeed - I may have communicated that thought in reverse :) | 14:32 |
jeblair | mordred: cool, so let's prioritize thusly: soon, let's land a simple web page to facilitate web log streaming and hook that up to the existing status page. then work on the dashboard as we're able. | 14:33 |
jeblair | mordred: can you look at these items on my punchlist from last week? 481773, 479084, 481824 ? | 14:35 |
mordred | jeblair: ++ | 14:37 |
mordred | Shrews: do you think you can take the tobiash patch and wire it in so that zuul-web serves it from somewhere? like maybe /static/stream or something and that we then change the part of the status page that shows finger:// to show /static/stream.html?build_id={build_id} or something? I think we still want the finger:// to be in the status.json so that we could have status.json ALSO show the finger link | 14:44 |
mordred | Shrews: also - there is currently a big in the tobiash patch where it has var zuulBaseURL = "<ADD YOUR ZUUL BASE URL HERE>" - but I believe if we're serving that page we can assume the zuul base url to be / - right? | 14:45 |
Shrews | mordred: i can take a look. as for zuulBaseURL... maybe? I'm not a web dev (enjoy doing that as much as I enjoy java), but that seems a reasonable thing to assume | 14:49 |
Shrews | tobiash: mind if I take over your example patch? | 14:49 |
mordred | Shrews: yah - I think that's the 'right' way we want to do this - assume that the web url from which the html page is served shares the same host, so just using the relative path of /zuul/console-stream rather than needing to add zuulBaseURL at all | 14:50 |
jeblair | mordred: ++ | 14:51 |
mordred | Shrews, jeblair: also, I was thinking a '/static' prefix to make it easy for folks to make an apache/nginx rewrite rule to serve static assets like that html page directly rather than strictly needing aiohttp to serve them | 14:52 |
jeblair | mordred: i agree that's a good practice. | 14:52 |
*** isaacb has quit IRC | 14:59 | |
jeblair | Shrews: is my reply in https://review.openstack.org/474369 convincing enough for a +3? | 15:00 |
mordred | pabelanger: I don't know if you're back today or not. If you are, just a heads up that I've started poking at your configure-mirror patch - so don't dive back in to it without pinging | 15:01 |
mordred | pabelanger: also - we got a BUNCH done in base jobs and job structure - happy to walk you through where things are whence you return | 15:01 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Pass result data back from ansible https://review.openstack.org/479442 | 15:02 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Support relative urls in success-url https://review.openstack.org/481342 | 15:02 |
jeblair | mordred: can you re +2 479442? it merge conflicted with retry_limit | 15:05 |
*** jkilpatr has joined #zuul | 15:06 | |
openstackgerrit | Merged openstack-infra/nodepool feature/zuulv3: Add image-id and image-name options to cloud-images https://review.openstack.org/474369 | 15:11 |
mordred | jeblair: oh - also, I pushed up https://review.openstack.org/#/c/481942/ as straw-man first step for being able to make zuul_stream (or something) be able to distinguish between pre/run/post for display purposes | 15:24 |
jeblair | mordred: nifty! | 15:26 |
jeblair | mordred: it looks like the playbook does not show up in job-output.txt. i think that would be useful? | 15:29 |
jeblair | er | 15:29 |
jeblair | mordred: i mean the playbook summary output | 15:29 |
jeblair | 'play recap'. that's what it's called | 15:30 |
jeblair | 2017-07-10 15:12:12,403 DEBUG zuul.AnsibleJob: [build: f6573fd53a014821aad373e1282a06e2] Ansible output: b'PLAY RECAP *********************************************************************' | 15:30 |
jeblair | 2017-07-10 15:12:12,403 DEBUG zuul.AnsibleJob: [build: f6573fd53a014821aad373e1282a06e2] Ansible output: b'localhost : ok=4 changed=4 unreachable=0 failed=0' | 15:30 |
jeblair | 2017-07-10 15:12:12,403 DEBUG zuul.AnsibleJob: [build: f6573fd53a014821aad373e1282a06e2] Ansible output: b'static.openstack.org : ok=3 changed=2 unreachable=0 failed=0' | 15:30 |
jeblair | that thing | 15:30 |
*** isaacb has joined #zuul | 15:38 | |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Make sure bindep is on the node https://review.openstack.org/481817 | 15:39 |
*** isaacb has quit IRC | 15:40 | |
*** isaacb has joined #zuul | 15:41 | |
*** jkilpatr has quit IRC | 15:48 | |
mordred | jeblair: yah - we can output one of those - we just need to add the right callback method to zuul_stream (we're an opt-in callback rather than an opt-out callback at this point) | 15:53 |
jeblair | mordred: cool | 15:54 |
tobiash | Shrews: feel free | 15:56 |
Shrews | mordred: hrm, i'm going to have to actually setup an actual zuul in order to test/verify the zuul-web change you requested. will have to spend some time learning how to actually do that | 16:03 |
Shrews | hopefully i can use jlk's docker-compose stuff | 16:03 |
jlk | oh hi | 16:03 |
jlk | jamielennox: is also working on zuul in kubernetes, and that is likely worth looking at too. | 16:04 |
jlk | oh just for testing, yeah the docker-compose is pretty easy to fire off | 16:04 |
Shrews | jlk: yeah, i'm already familiar with docker so will try that route | 16:05 |
Shrews | jlk: though docker swarm is new to me | 16:10 |
Shrews | jlk: tl;dr for that? | 16:10 |
jlk | the way I'm using it is just a single node swarm | 16:10 |
jlk | it _could_ be multiple docker nodes that the containers get spread across | 16:10 |
jlk | proto-k8s | 16:10 |
jlk | I'm only using swarm in local mode to better handle secrets | 16:11 |
Shrews | jlk: so i don't need to do that? | 16:12 |
*** jkilpatr has joined #zuul | 16:12 | |
jlk | You might not get your zuul.conf or clouds.yaml file loaded into the container correctly without doing that. | 16:13 |
jlk | however, you can turn a single docker host into "swarm" mode with just a couple commands. | 16:13 |
jlk | "docker swarm init" I think | 16:14 |
jlk | may only need that one command. | 16:14 |
SpamapS | I'm curious how much different this is if you just use a local k8s and helm or something. | 16:14 |
*** isaacb has quit IRC | 16:16 | |
Shrews | jlk: do i just set ZUUL_REPO env var to override to a local checkout? | 16:21 |
Shrews | oh, ZUUL_SRC | 16:22 |
* Shrews should actually read the README | 16:23 | |
jeblair | mordred: I6daa045d3f2ccb1540d64e81f7fc825eed08b2d4 should Depends-On: Icfbef10b1bcf36d75f961cd4319bc062a77efe2a right? | 16:23 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Rework bindep role to be more ansible and less shell https://review.openstack.org/481818 | 16:23 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Clean up debug-ansible role https://review.openstack.org/481819 | 16:24 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Fail if traceroute doesn't work https://review.openstack.org/481949 | 16:24 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Move node debug information into a directory https://review.openstack.org/481944 | 16:24 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Rename debug-ansible to validate-host https://review.openstack.org/481826 | 16:24 |
jeblair | mordred: which just merged so it's moot. :) | 16:25 |
mordred | Shrews: re: websocket abort exceptions - is there a difference between clean and unclean abort? like - potentially we should be able to make our web client thing cleanly disconnect so that that doesnt' show an exception, yeah? | 16:33 |
mordred | Shrews: (doesn't need immediate answer - I'm mostl just thinking out loud) | 16:34 |
Shrews | mordred: can an asyncio thing be cleanly aborted? | 16:34 |
Shrews | mordred: my immediate concern in the comment I left there was "let's not lose unexpected exceptions" over "let's cleanup abort" | 16:36 |
Shrews | the clean abort may very well be valid and something we should do, but removing the log entry is not the solution for that | 16:36 |
Shrews | mordred: ^^^ | 16:36 |
mordred | Shrews: there is a CLOSE even type ... | 16:36 |
mordred | Shrews: and yes - I agree | 16:37 |
jlk | Shrews: funny you should ask that, I _just_ added that bit to the README as we were talking :D | 16:37 |
*** harlowja has joined #zuul | 16:37 | |
Shrews | jlk: oooh, THAT'S why the github readme didn't match the version i just pulled from github | 16:38 |
Shrews | i wondered how that happened | 16:38 |
jlk | sneaky sneaky! | 16:38 |
Shrews | jlk: do i need a certain docker version? | 16:41 |
Shrews | jlk: "ERROR: Version in "./docker-compose.yaml" is unsupported" | 16:41 |
jlk | Oh are you getting warnings about secret file format? | 16:41 |
jlk | hrm. | 16:41 |
jlk | docker-compose version 1.14.0, build c7bdf9e | 16:42 |
jlk | Docker version 17.06.0-ce, build 02c1d87 | 16:42 |
Shrews | i have 1.9.0 (latest fedora) | 16:42 |
jlk | that might not be new enough? | 16:43 |
Shrews | possible. looking at upgrade options | 16:43 |
jeblair | i'm not sure i've ever heard of latest fedora not having a new enough anything before. | 16:43 |
jlk | https://docs.docker.com/compose/compose-file/compose-versioning/ | 16:44 |
jlk | you'll need docker-compose at least 1.11 | 16:46 |
jlk | https://github.com/docker/compose/releases/tag/1.11.0 | 16:46 |
Shrews | well... | 16:48 |
jlk | looking at Fedora packagedb, looks like there were some newer builds | 16:48 |
Shrews | i just followed https://docs.docker.com/engine/installation/linux/docker-ce/fedora | 16:48 |
Shrews | to get the latest | 16:48 |
jlk | not sure where they are in the update process. | 16:48 |
Shrews | and i now have... 1.9.0 | 16:48 |
jlk | waaaat | 16:48 |
jlk | oh, you're on f25, f26 isn't out yet? | 16:48 |
jeblair | tomorrow, apparently? | 16:49 |
Shrews | perhaps docker-ce does not include docker-compose? | 16:50 |
jlk | okay, so f26 does have newer docker-compose. | 16:50 |
jlk | what does docker --version say? | 16:50 |
Shrews | yay, no work until tomorrow! | 16:50 |
Shrews | Docker version 17.06.0-ce, build 02c1d87 | 16:50 |
jlk | okay, yeah you're engine version is the latest | 16:51 |
Shrews | i now, perhaps, need to undo the things i just did | 16:51 |
jlk | it's just your compose version isn't. | 16:51 |
jlk | software packaging and delivery is hard. Lets go ride bikes! | 16:52 |
jlk | (wait, no, I do NOT want to ride a bike today...) | 16:53 |
jeblair | Shrews: actually i do have a suggestion of something you could do before starting work on the html thing -- can you make a followup change to 463353 that adds documentation? while you were gone, we landed the doc update/reorg patches, so zuul docs are now current. we should start making sure changes are accompanied with docs now. | 16:54 |
Shrews | jeblair: yes, good idea | 16:54 |
jlk | yaaay changes with docs ++ | 16:55 |
Shrews | as soon as i figure out how to tell dnf to remove the custom repo i just added | 16:55 |
jeblair | Shrews: probably want to just base the docs change on the branch tip since that's where the docs are, rather than 463353. it'll be right when they all merge. ;) | 16:56 |
jeblair | (i'm trying to avoid a rebese for 353) | 16:56 |
Shrews | ++ | 16:56 |
Shrews | jeblair: also, if you are reviewing 353 now, the "if __name__ == '__main__'" section at the bottom of zuul/web.py (used for testing) is no longer valid since I removed the default parameter values from ZuulWeb with this morning's changes. I can change that in a follow up, unless you find something else that needs immediate attention. | 17:15 |
jeblair | Shrews: i am reviewing now. that sounds like a plan. | 17:16 |
*** jkilpatr has quit IRC | 17:19 | |
jlk | A friend of mine, an Ansible network module dev at F5, brings up an interesting use case (he's looking at zuul) | 18:01 |
*** dmellado has quit IRC | 18:02 | |
*** dmellado has joined #zuul | 18:02 | |
jlk | in one of his tests, he needs to test a large number of drivers, and wants to test them all in parallel. But they can all be done locally, so what he's doing is running one playbook to generate an inventory of fake hosts that all are local connection, then calling another playbook with a large number of forks, so that he gets lots of things happening locally at the same time. | 18:02 |
jlk | we're talking through how that would look in zuul land, if there is anything in zuul that would make that easier. I don't tink there is because it would require passing a custom inventory (and fork option) to the ansible execution | 18:03 |
mordred | jlk: yah - I mostly agree with your conclusion. I think that woudl just all be ansible he ran on a remote host | 19:00 |
mordred | jlk: that said - that could ALSO be done as a ton of jobs in zuul so that the second playbook just gets called with hosts: all - likely doesn't make a ton of sense with the vms from nodepool - but containers from nodepool might make that nice | 19:02 |
jeblair | mordred, jlk: ++ | 19:30 |
jeblair | Shrews: there was a suggestion about ignoring the exception raised by client disconnects. you didn't accept it because you didn't want to ignore other errors. is a CancelledError specific enough we can catch that one and ignore it, but not others? | 19:37 |
jeblair | Shrews: i'm pushing on this a little bit because gerrit logs all client disconnect errors as exceptions, and it has rendered the gerrit log completely useless. like i can't even begin to describe how much we don't ever look at that at all. | 19:38 |
jeblair | (clients disconnect from network services *all the time*; that is not an exceptional condition.) | 19:39 |
jeblair | Shrews: 463353 +3 with comments | 19:43 |
jeblair | mordred: should we refresh https://review.openstack.org/473966 and merge it soon? | 19:55 |
mordred | jeblair: yes | 19:58 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Make sure we always log the exit line https://review.openstack.org/473966 | 20:01 |
*** jkilpatr has joined #zuul | 20:07 | |
jeblair | mordred: where's the subunit2html processing/copying on your list? i notice we don't seem to be getting that for py35 jobs at the moment (though we *are* getting the tox/ dir) | 20:08 |
mordred | jeblair: next after I get configure-mirror done | 20:09 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add web-based console log streaming https://review.openstack.org/463353 | 20:09 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add support for zuul.d configuration split https://review.openstack.org/473764 | 20:09 |
jeblair | mordred: cool | 20:10 |
*** jkilpatr has quit IRC | 20:21 | |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Make sure we always log the exit line https://review.openstack.org/473966 | 20:37 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Actually run the unittests post playbooks https://review.openstack.org/482282 | 20:38 |
Shrews | jeblair: oh, my disagreement wasn't with the fact that the abnormal abort shouldn't be handled. I disagreed with the suggested way to handle it (remove the logging). | 20:40 |
Shrews | jeblair: we'll have to get more info on the "abort" method b/c i haven't seen that traceback at all in my testing | 20:40 |
Shrews | so i'm puzzled what would cause that | 20:41 |
jeblair | mordred: i think i spot a problem with implict self-role. we throw errors if there is a *_plugins directory adjacent to a role. so if someone adds to cloudkitty, we're going to try to add the cloudkitty repo as a role repo. if cloudkitty isn't actually a role repo, that's probably fine, except that we're going to assume that, since it doesn't have a tasks/ or roles/ directory, that it's a "collection of roles" repo. if any subdir has a ... | 20:41 |
jeblair | ... *_plugins directory, we'll fail the job. basically, if cloudkitty defines a job and has a directory entry matching */*_plugins, we're going to fail. | 20:41 |
jeblair | mordred: it's a small problem, to be sure, but still, i don't have an answer for it. | 20:42 |
mordred | jeblair: hrm. that's a good one | 20:42 |
jeblair | mordred: we could further restrict the kind of roles used in an implicit self-role. i don't like that because it's just more magic rules to know about.... | 20:43 |
mordred | jeblair: my first thought is to not allow "collection of roles" repos for implicit self adding, but that seems like a byzantine rule | 20:43 |
mordred | jeblair: jinx | 20:43 |
jeblair | heh | 20:43 |
mordred | jeblair: do we have any specific examples of collection-of-roles directories where the roles are not in a directory called roles? | 20:44 |
mordred | like - I remember we added that for a reason - but I'm struggling to wrap my head around the specific reason | 20:45 |
jeblair | mordred: hrm; i'm not sure where that came from. probably should annotate these if we figure it out. | 20:45 |
jeblair | jlk: ^ seen anything like that in your experience? | 20:46 |
*** jkilpatr has joined #zuul | 20:46 | |
*** jkilpatr has quit IRC | 20:48 | |
*** jkilpatr has joined #zuul | 20:48 | |
jlk | I have not, although I haven't used or interacted with many roles repos to begin with | 20:49 |
mordred | jeblair: https://github.com/ansible/ansible/issues/16804 | 20:49 |
mordred | there is apparently an undocumented accidental feature in galaxy that allows you to use a repo with multiple roles in it from galaxy if that repo has a meta/main.yml file in it | 20:49 |
mordred | bcoca points out that it is not an actual contract | 20:49 |
mordred | and suggests that the feature desire be proposed and documented | 20:50 |
mordred | but - we could decide to never consider a repo a "collection of roles" automatically if it doesn't have a meta/main.yml file - and wait until someone gets upset that they want to use zuul with a repo that is a collection of roles where they do not want a meta/main.yml file to exist | 20:51 |
Shrews | jeblair: also, for the CancelledError exception, I think that's pretty normal with asyncio? There might be some cleanup we need to do during shutdown to avoid that. But this is us/me learning about asyncio. :) | 20:51 |
Shrews | jeblair: can look into it more when i have a working setup | 20:51 |
jlk | mordred: that seems like a fine plan | 20:52 |
mordred | we're not using galaxy to clone git repos- so it would not actually matter if galaxy stopped accidentally supporting multi-role repos in that format - there's not a high cost to someone adding such a file | 20:52 |
jlk | mordred: and when said meta/main.yaml at the top level gets a contract for what content should be in it, we can follow suit. | 20:52 |
mordred | yup | 20:53 |
jeblair | Shrews: okay cool -- i think tobiash was suggesting that we only ignore CancelledError, based on the idea that represents an aborted connection. it sounds like we're all on the same page (don't log useless info), and we just need to narrow that down. | 20:57 |
Shrews | jeblair: yeah, i mean... if that exception is a thing you see only once (at shutdown) it's likely not a big deal. but if there is something else that's being abort to cause that during a run, then that would totally be annoying. my impression was that it was the first thing | 20:59 |
Shrews | but i need something in place to dig more | 20:59 |
jeblair | Shrews: oh, yeah. i think we were reading "abort" differently. i agree with your conclusion based on your reading. :) | 21:00 |
jeblair | Shrews: (i was reading it as "remote user hung up during negotiation" or something like that) | 21:00 |
jeblair | meat-based communication is fun | 21:01 |
Shrews | tobiash: please define "abort" for jeblair and myself when you are around :) | 21:01 |
*** dkranz has quit IRC | 21:02 | |
Shrews | i don't think a client can cause asyncio to abort an event loop task (i would expect another error), but i could be wrong | 21:03 |
Shrews | yay new things \o/ | 21:04 |
mordred | from my reading - the browser should be causing a CLOSE event to happen on the websocket | 21:05 |
jeblair | and that one is handled | 21:05 |
mordred | when the broswer window closes or naviates away | 21:05 |
mordred | yah | 21:05 |
jeblair | mordred: but maybe if you just kill the tcp connection something else happens...? | 21:06 |
mordred | maybe so - I would hope we can detect the difference? | 21:06 |
mordred | in any case - I am excited to learn more from tobiash | 21:06 |
Shrews | i would hope so. i mean, "client disconnected" is a radically different thing from "this event loop task was cancelled". | 21:07 |
Shrews | i'd hope we'd be able to detect the first | 21:07 |
jeblair | mordred, jlk: okay, so resolution is to drop the collection-of-roles case? i think that implies that we should hard-fail if a specified role repo lacks either a tasks or roles directory, but soft-fail (ie, simply do not add the repo to the roles path) if it's an implicit role repo. sound right? | 21:12 |
jeblair | or -- should we soft-fail in all cases? (that would let you specify a roles: repo that has no roles and is not a role and not cause an error) | 21:14 |
jeblair | (that's actually close to the case today, where the soft fail is "mostly harmlessly add the whole repo to the roles path") | 21:14 |
*** jkilpatr has quit IRC | 21:17 | |
jlk | hrm. Given that we have some strict rules about what can be in those repos, I think I"d prefer to explicitly fail instead of quietly either letting it happen and maybe work, or misinterpreting the user's intent | 21:18 |
openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Fix ZuulWeb() invocation https://review.openstack.org/482321 | 21:22 |
Shrews | jeblair: ^^^ that fix i promised earlier | 21:22 |
jlk | jeblair: which cloudkitty repo could be causing a problem? | 21:22 |
jeblair | jlk: oh, none in particular. it's just my favorite example of "hypothetical zuul end user". :) | 21:23 |
jlk | OIC | 21:23 |
jeblair | cloudkitty is a metasyntactic variable | 21:23 |
mordred | jeblair: I think we should hard-fail on explicit | 21:25 |
jeblair | jlk, mordred: ok, i'll take a crack at the first thing then -- hard-fail if you explicitly add a roles repo, and soft-fail if it's implicitly added. | 21:25 |
mordred | jeblair: I'm fine dropping collection of roles - or with changing the collection-of-roles detection to require a meta/main.ya?ml file | 21:25 |
jeblair | mordred: i'll drop for now, and we can add it back later if it's still a real thing. :) | 21:28 |
mordred | jeblair: kk | 21:32 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Fail execution if a role repo is a bare collection of roles https://review.openstack.org/482327 | 21:33 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Actually run the unittests post playbooks https://review.openstack.org/482282 | 21:35 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul-jobs master: Fix a playbook typo https://review.openstack.org/482329 | 21:36 |
mordred | jlk: :) | 21:36 |
jlk | mordred: haha, https://review.openstack.org/482282 is fixed by ^^ | 21:36 |
mordred | jlk: I think we found the same thing at the same time | 21:36 |
mordred | jlk: fwiw, always feel free to just edit any of my patches for stuff like that | 21:37 |
jlk | I'lld rop mine | 21:37 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Fix a playbook typo https://review.openstack.org/482329 | 21:37 |
mordred | jlk: nah - I just +3'd it | 21:37 |
mordred | it's a good self-contained fix | 21:37 |
jlk | but then it'll conflict with yours... | 21:37 |
mordred | it should magic itself I believe - they do the same thign - git's pretty good at no-oping that conflict | 21:38 |
jlk | hrm. I wouldn't think so, because the git blame will be conflicting. | 21:38 |
jlk | how does it determine who's is right? | 21:38 |
jlk | pretty certain it'll just result in a merge conflict. | 21:39 |
mordred | jlk: git blame should go to the first one to land - we'll find out in just a sec :) | 21:40 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Actually run the unittests post playbooks https://review.openstack.org/482282 | 21:51 |
mordred | jlk: turns out I needed to update it more anyway :) | 21:51 |
jlk | indeed | 21:53 |
openstackgerrit | Merged openstack-infra/zuul-jobs master: Actually run the unittests post playbooks https://review.openstack.org/482282 | 21:56 |
jeblair | it's zuul meeting time in #openstack-meeting-alt | 22:00 |
openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Add link to Zuul v3 docs to the README https://review.openstack.org/482349 | 22:23 |
*** jkilpatr has joined #zuul | 23:23 | |
mordred | pabelanger: happy to have you back! tons of progress on jobs ... will fill you in whenever you're ready for it | 23:54 |
pabelanger | mordred: excellent! Should be ready to start back at it first thing tomorrow morning | 23:54 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!