| *** jesusaur has quit IRC | 00:42 | |
| *** eumel8 has quit IRC | 01:24 | |
| *** rbergeron has quit IRC | 02:48 | |
| *** jesusaur has joined #zuul | 03:38 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: executor: enable inventory to be updated with zuul_return https://review.openstack.org/590092 | 04:12 |
|---|---|---|
| *** jesusaur has quit IRC | 04:46 | |
| *** jesusaur has joined #zuul | 04:48 | |
| *** eumel8 has joined #zuul | 05:36 | |
| *** AJaeger has quit IRC | 06:16 | |
| ianw | mordred / corvus : i don't know what i'm missing here ... http://logs.openstack.org/35/589335/12/check/openstack-infra-base-integration-fedora-latest/9f1b6c6/ara-report/ | 06:21 |
| ianw | import_playbook: openafs-client.yaml | 06:22 |
| ianw | when: ansible_os_family == 'Debian' or ansible_distribution == 'CentOS' | 06:22 |
| ianw | that playbook has two included roles -- install kerberos and install openafs -> https://review.openstack.org/#/c/589335/12/tests/openafs-client.yaml | 06:23 |
| ianw | it seems to skip everything for the kerberos-client role. but then it tries to run the openafs-client role? | 06:25 |
| *** pcaruana has joined #zuul | 06:38 | |
| *** gtema has quit IRC | 07:16 | |
| *** darkwisebear has joined #zuul | 07:35 | |
| *** jpena|off is now known as jpena | 07:50 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Support job pause https://review.openstack.org/585389 | 08:07 |
| *** gtema has joined #zuul | 08:16 | |
| *** mhu has joined #zuul | 08:44 | |
| *** electrofelix has joined #zuul | 09:11 | |
| *** darkwisebear has quit IRC | 09:39 | |
| openstackgerrit | Markus Hosch proposed openstack-infra/nodepool master: Add list of metrics provided to statsd https://review.openstack.org/590233 | 10:31 |
| *** jpena is now known as jpena|lunch | 11:01 | |
| *** snapiri has quit IRC | 11:25 | |
| *** snapiri has joined #zuul | 11:25 | |
| *** jpena|lunch is now known as jpena | 11:58 | |
| pabelanger | morning! | 12:10 |
| pabelanger | +3 on 589563, openstacksdk bump | 12:10 |
| pabelanger | Shrews: tobiash: corvus: clarkb: It seems softwarefactory is having an issue with an exception being raised in the lauch-retries loop when trying to delete a node: https://review.openstack.org/589854/ I haven't reviewed the chance yet, but wanted to see if you'd add it to your review pipeline. cc mhu | 12:15 |
| mhu | pabelanger, thx - I'm not sure simply logging the failure is right, so advice on this is more than welcome | 12:16 |
| tristanC | perhaps a cleanup-retries option to safely retry? | 12:21 |
| tristanC | or a request-retries in zuul to restart the request loop instead of returning node_error | 12:22 |
| openstackgerrit | Merged openstack-infra/nodepool master: Bump minimum openstacksdk version to 0.17.2 https://review.openstack.org/589563 | 12:35 |
| *** darkwisebear has joined #zuul | 12:36 | |
| Shrews | pabelanger: the thing to do there might be to just create a new node to reference the instance and move on rather than wait for the delete. tobiash should weigh in on that idea though | 12:38 |
| pabelanger | mhu: ^ | 12:44 |
| *** ianychoi has quit IRC | 12:49 | |
| *** darkwisebear has quit IRC | 13:00 | |
| mordred | pabelanger, mhu: is this a different issue from the task manager issue that was fixed in 0.17.2 ? | 13:41 |
| mhu | mordred, I think so. The issue would occur every time the cleanupNode call raises an exception | 13:43 |
| mordred | ah - gotcha | 13:43 |
| pabelanger | mordred: mhu: yes, this is related to single cloud use case and wanting a node not to return NODE_FAILURE. | 13:47 |
| pabelanger | which happens when we raise the delete exception | 13:47 |
| mordred | single cloud vs. multiple cloud are a little different aren't they? | 13:48 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: executor: enable inventory to be updated with zuul_return https://review.openstack.org/590092 | 13:49 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: executor: add support for generic build resource https://review.openstack.org/570668 | 13:49 |
| pabelanger | mordred: yah, most of the feedback (and time) at the moment, is trying to keep cloud related failures away from users running jobs. Even if this means a job is enqueued for hours while there is a cloud outage | 13:50 |
| pabelanger | each time zuul reports a NODE_FAILURE, users seem to get less happy :( | 13:51 |
| tristanC | also, when there is a node_failure, end_time is null, could we revisit https://review.openstack.org/535549 please? | 13:52 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift resource provider https://review.openstack.org/570667 | 13:53 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool master: Implement an OpenShift Pod provider https://review.openstack.org/590335 | 13:53 |
| Shrews | after more thinking, i'm fairly confident shifting the instance deletion work to the delete thread is the proper thing to do there | 13:59 |
| Shrews | so, create new DELETING node with the instance id, store it, move on | 14:00 |
| Shrews | also keeps the delete work in one place, as it was intended to be | 14:04 |
| pabelanger | Shrews: ++ | 14:06 |
| pabelanger | mhu: do you want to refresh your patch above based on Shrews feedback? | 14:07 |
| pabelanger | not sure if we also have a way to add a test too | 14:07 |
| mhu | pabelanger, Shrews ok so just changing the node status to DELETING is enough? | 14:08 |
| Shrews | there should be a way to test that. tobiash already has one iirc. | 14:08 |
| tristanC | Shrews: isn't that going to bubbleup the quota calculation? | 14:09 |
| Shrews | mhu: i think there might other properties you'll need to set... provider maybe | 14:09 |
| pabelanger | tristanC: I thought we re-recalculated quota properly now with tobiash patch | 14:09 |
| pabelanger | between retries | 14:09 |
| Shrews | that's why i'd like tobiash's input on it | 14:10 |
| pabelanger | +1 | 14:10 |
| Shrews | re: quota | 14:10 |
| Shrews | so you might want to wait to see what he says | 14:10 |
| *** darkwisebear has joined #zuul | 14:11 | |
| Shrews | mhu: also, you're not *changing* the node status. you'd need to actually create a *new* node object | 14:11 |
| Shrews | something like: tmp_node = zk.Node(); tmp_node.state = zk.DELETING; tmp_node.provider = self.node.provider; yadda yadda yadda | 14:14 |
| mhu | gotcha, thx | 14:17 |
| *** samccann has joined #zuul | 15:08 | |
| clarkb | Shrews: pabelanger: the more these issues pop up the more I think we may need to consider decoupling the node requests from specific boots. Old nodepool basically processed requests in a true fifo, request A and B come in. Start booting nodes, first one up goes to A then next up goes to B without direct mapping between the two until that point | 15:21 |
| clarkb | thats a fairly big change to nodepool though | 15:22 |
| corvus | clarkb: what other issue would be solved by that? | 15:37 |
| clarkb | corvus: long delays before jobs start if they go through multiple retries in cloud A before heading to cloud B | 15:38 |
| clarkb | corvus: users often ask why their jobs haven't started yet and ^ seems to be a common cause. | 15:38 |
| clarkb | We could have it retry globally rather than individual clouds if we decoupling the request handling from specific clouds | 15:38 |
| clarkb | *if we decoupled | 15:39 |
| corvus | clarkb: the old nodepool didn't *have* requests, it just tried to guess how many nodes the system needed as a whole and threw them at jenkins and hoped for the best. | 15:40 |
| clarkb | ya, they were inferred requests based on queue lenghts | 15:40 |
| corvus | jobs would run in semi-random order based on how jenkins assigned the nodes | 15:41 |
| corvus | now we *actually* have a queue and have some control the ordering of node delivery, modulo the performance of clouds as you point out | 15:41 |
| corvus | the request system lets us do a lot of things we couldn't before -- like prioritize node requests by pipeline (we service high priority pipelines first), and true multi-node support (with different types of nodes) | 15:42 |
| corvus | i don't think we should go back | 15:42 |
| clarkb | corvus: I'm not suggesting going back. But instead putting a proxy in between cloud providers and zuul requests | 15:43 |
| Shrews | i have this idea in the back of my mind for nodepoolv4 of having a scheduler process to do the request assignment (supporting round robin, provider priority, first available, etc). but that's far down the road | 15:43 |
| clarkb | something that can paper shuffle a bit more intelligently | 15:43 |
| clarkb | corvus: Zuul says "I need a node of type foo", nodepool asks some cloud to boot another type foo, then whenever any type foo comes back it is given to that first zuul request | 15:45 |
| pabelanger | Shrews: it is good you are thinking about it, one topic that keeps coming up downstream is for the neat to better control which provider runs a job. EG: time of day usage, due to provider costs | 15:45 |
| clarkb | in current system that request can only be served directly currently. Which means we may have booted 5 other type foos in that time span | 15:45 |
| corvus | Shrews: yeah, that's an option -- or we can also look at having more cooperative launchers | 15:45 |
| corvus | Shrews: if you add in a scheduler, we'd need to add in *multiple* schedulers. nodepool is currently our most distributed system. zuul is not a model to follow here -- it's the other way around :) | 15:46 |
| Shrews | corvus: absolutely | 15:46 |
| clarkb | corvus: Shrews ya Iwouldn't add a spof zuul, each launcher could just run the request handler thread and be responsible for those it pulls off of zk | 15:46 |
| clarkb | the drawback is now your failure domains are in multiple axis | 15:47 |
| corvus | Shrews, clarkb: but one way or another, i think there is room for some more decoupling here. | 15:47 |
| clarkb | *spof like zuul. ugh brain not typing good today | 15:48 |
| corvus | at any rate, i think Shrews's idea for handing off the delete action is a good fix in the current system. | 15:48 |
| pabelanger | I think so far, at least in rdo, the new launcher has worked well. It is just in our case, we only have 1 provider, which has a fair bit of outages. If we had another provider, I don't think the users would complain as much | 15:49 |
| clarkb | pabelanger: ya and end of day if you only have one provider and it is down then no jobs are going to run | 15:49 |
| clarkb | (no matter how smart nodepool is trying to be) | 15:49 |
| pabelanger | exactly | 15:50 |
| pabelanger | I've been trying to express that to mgmt, while making nodepool better for single cloud is great, we really should be working to fix the cloud or add more clouds. | 15:50 |
| corvus | ++fix the cloud makes things better for everyone. customers included. :) | 15:50 |
| pabelanger | right, just very hard when you have control over said cloud. | 15:51 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: DMN - testing base-test https://review.openstack.org/590407 | 15:53 |
| *** gtema has quit IRC | 16:02 | |
| *** jpena is now known as jpena|off | 16:07 | |
| openstackgerrit | Markus Hosch proposed openstack-infra/nodepool master: Add metric for image build result https://review.openstack.org/590412 | 16:16 |
| tristanC | clarkb: it's not entirely down, it's just that sometime, for a short period of time, node creation and deletion fail leading to un-necessary node_failure error | 16:31 |
| * tobiash is reading backlog | 16:36 | |
| *** darkwisebear has quit IRC | 16:37 | |
| clarkb | tristanC: if you can't create or delete nodes wouldn'y you call that down? | 16:37 |
| tristanC | the running job may complete correctly | 16:38 |
| clarkb | ya the existing intsances don't have an outage but the cloud does | 16:39 |
| corvus | suprisingly, this seems to be a disagreement of what "it" is referring to. :) i guess what is meant is that the control plane may not be functioning, but the hypervisors are. | 16:39 |
| corvus | (or, rather, if "it" is "the cloud" then a disagreement over what "the cloud" refers to :) | 16:41 |
| * corvus shakes fist at cloud | 16:41 | |
| clarkb | it is an important distinction, it just happens that nodepool's primary duties are creating and deleting instances so that is the outage it cares about | 16:41 |
| Shrews | it also depends on what your definiton of "is" is | 16:42 |
| * Shrews watches the 90's reference go over heads | 16:42 | |
| tristanC | clarkb: and it seems like this is happening during short period of time, it just need a single deletion exception to result in a build failure | 16:43 |
| clarkb | tristanC: but only if the build failed first right? | 16:43 |
| clarkb | (it is a situation we should handle, mostly just agreeing that outages like that being fixed make everyone happy including nodepool) | 16:44 |
| tristanC | yes, deletion error after build failure | 16:44 |
| pabelanger | when i last looked (not today), nodepool failed to launch a node (due to FIP timeout when server first came online), then we also failed to delete. Both times looks like api_timout in clouds.yaml (60 seconds) was hit | 16:45 |
| pabelanger | I suspect, in the cloud, something caused the load to raise up and stop responding fast enough to the request | 16:45 |
| mordred | pabelanger: in the past when we'vehad clouds hit api timeouts (/me looks at HP) it was mostly related to db indexing issues on the cloud in question | 16:46 |
| mordred | fwiw | 16:46 |
| mordred | pabelanger: but now I'm just backseat driving :) | 16:46 |
| pabelanger | yah, I think there is a few issues TBH. Wouldn't be surprised if database was involved, I actually wonder if they have it backed with ceph. | 16:48 |
| tobiash | pabelanger, Shrews: ++ for creating new node and offloading deletion to the delete worker | 16:49 |
| pabelanger | mhu: ^ | 16:49 |
| pabelanger | tobiash: thanks for confirming! | 16:49 |
| tobiash | also the quota calculation should be fine as the aborted node is deleted short after | 16:49 |
| tristanC | clarkb: agreed there is an issue with the cloud, but it may be better if zuul/nodepool would retry a bit more before resulting in a node_failure | 16:50 |
| tobiash | what won't work is to reuse the node and just set it to deleting as the node needs to be in aborted state in case of a quota error | 16:50 |
| tobiash | also quota calculation should be fine as any node is counted towards the estimated quota but the aborted nodes are deleted quickly and a node in deleting state must be calculated into the quota | 16:51 |
| openstackgerrit | Markus Hosch proposed openstack-infra/nodepool master: Add metric for image build result https://review.openstack.org/590412 | 17:02 |
| *** darkwisebear has joined #zuul | 17:03 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP Map file comment line numbers https://review.openstack.org/590429 | 17:03 |
| corvus | mordred, tobiash, jhesketh: ^ okay, that's a little wonky, but now that i've got it sketched out, i think i can tidy things up a bit | 17:04 |
| tobiash | corvus: what do you think about maybe doing this directly on the executor after ansible finished instead of doing another merger call? | 17:08 |
| corvus | tobiash: we can't guarantee the state of the git repos then (the job could delete them) | 17:09 |
| tobiash | corvus: oh that's right | 17:09 |
| corvus | tobiash: we could say that's a pathological case and just decide to skip line mapping if that happens, but we would still need to handle things like checking out the right branch/commit, etc, since it's much more reasonable for a job to have checked out different branches | 17:10 |
| tobiash | corvus: just thought we can save that but you convinced me that that's a bad idea :) | 17:12 |
| *** darkwisebear has quit IRC | 17:13 | |
| corvus | tobiash: heh, i'm not 100% convinced :) | 17:13 |
| tobiash | corvus: related to that, do we 'git fetch' on every merger call even if we have a repo state and have already every ref needed? | 17:16 |
| tobiash | what would be cool is if we could avoid to do yet another git fetch just because of line mapping | 17:17 |
| corvus | yes we do; we rely on git being efficient (if it has everything, it will only need to exchange the ref list, but that can still be slow on repos with lots of refs) | 17:19 |
| openstackgerrit | Matthieu Huin proposed openstack-infra/nodepool master: Do not abort node launch if failed node cannot be deleted https://review.openstack.org/589854 | 17:19 |
| tobiash | ah good | 17:20 |
| tobiash | from which kernel version did you upgrade your executors? | 17:21 |
| corvus | pabelanger, clarkb: ^ maybe you know? | 17:21 |
| tobiash | I'm thinking if I should switch the openshift nodes from centos atomic (centos 3.10) to fedora atomic (4.17) | 17:22 |
| clarkb | it was ubuntu xenial hwe -1 to ubuntu xenial hwe current | 17:23 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP Map file comment line numbers (alternate) https://review.openstack.org/590442 | 17:24 |
| corvus | tobiash: ^ quick sketch of your suggestion (the merger and filecomment file changes would be about the same, i haven't copied them over yet) | 17:25 |
| pabelanger | corvus: tobiash: clarkb: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-07-24.log.html#t2018-07-24T16:04:16 includes version we upgraded from and to | 17:25 |
| tobiash | pabelanger: thanks, I searched a few days after that | 17:26 |
| pabelanger | np! | 17:27 |
| pabelanger | tobiash: what is your current kernel version? will be intersted to see what boost you get if you update | 17:31 |
| tobiash | pabelanger: my kernel version is 3.10 (the one from current centos atomic) | 17:32 |
| tobiash | pabelanger: but quantifying the boost won't be that easy as the hosts are shared by many different services | 17:32 |
| pabelanger | understood | 17:33 |
| clarkb | in our case I expect that many of the performance improvements around PTI (fallout from meltdown) are what have aided us | 17:34 |
| tobiash | we currently use 16 core, 64gb vms as openshift nodes which run 8 executors, 8 mergers, 3 elk stacks, several cassandra instances,... | 17:34 |
| pabelanger | http://grafana.openstack.org/d/T6vSHcSik/zuul-status?orgId=1&from=now-30d&to=now is pretty convincing when we rebooted with 4.15 kernels | 17:34 |
| clarkb | I recall reading that newer kernels are basically back to pre PTI performance levels | 17:34 |
| pabelanger | almost think we could stop ze11.o.o for now and see how 10 executors does again | 17:34 |
| tobiash | clarkb: ah so maybe I won't get such a speedup | 17:35 |
| tobiash | pabelanger: yes, I saw that and it was really impressive | 17:36 |
| *** gouthamr is now known as gouthamr_away | 17:37 | |
| tobiash | pabelanger: what happened around 2018-06-02 http://grafana.openstack.org/d/T6vSHcSik/zuul-status?orgId=1&from=now-6M&to=now&panelId=25&fullscreen ? | 17:38 |
| tobiash | looks like after that the load has increased a lot and now it's back to normal | 17:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Scope config line comments to change https://review.openstack.org/590446 | 17:38 |
| pabelanger | tobiash: not sure, when did we upgrade to ansible 2.5? Also, could be start of release count down for openstack | 17:39 |
| pabelanger | can look more shortly | 17:39 |
| tobiash | ah, right, that could be ansible 2.5 | 17:40 |
| tobiash | so ansible 2.5 made it worse and the kernel upgrade fixed it... | 17:40 |
| tobiash | interesting | 17:40 |
| pabelanger | yah, I haven't really profiled 2.5 myself, it was just pure chance when I see ze11.o.o doing more builds, that I noticed it was a different kernel | 17:41 |
| tobiash | it's also amazing to see how perfectly evenly the builds are distributed among the executors | 17:43 |
| corvus | tobiash: this is the magic: http://git.zuul-ci.org/cgit/zuul/tree/zuul/executor/server.py#n1808 | 17:46 |
| pabelanger | ha, ze02.o.o is up to 79 jobs atm. next closes is 57 :) | 17:49 |
| tobiash | that's cool | 17:50 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Scope config line comments to change https://review.openstack.org/590446 | 17:52 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Scope config line comments to change https://review.openstack.org/590446 | 17:59 |
| pabelanger | tristanC: left comment on https://review.openstack.org/590092/ mostly curious why we can't use add_host vs zuul_return | 18:03 |
| pabelanger | tobiash: eager to try: https://review.openstack.org/585389/ for zuul_return pause | 18:04 |
| pabelanger | if anybody else would like to review :) ^ | 18:04 |
| tobiash | works like a charm | 18:04 |
| pabelanger | Nice! | 18:05 |
| tobiash | just the second latest version of that change had a bug that a job without children which pauses never unpaused | 18:06 |
| tobiash | but that is fixed in the latest ps | 18:06 |
| pabelanger | ++ | 18:08 |
| pabelanger | will help rdo for sure, we upload a lot of artifacts to our logs.r.o server, and have some issue keeping up with crontab to delete stale artifacts | 18:08 |
| tobiash | pabelanger: you might be interested in swift logs upload, cleanup there is really neat | 18:11 |
| *** elyezer has quit IRC | 18:14 | |
| *** panda|ruck is now known as panda|ruck|off | 18:22 | |
| *** elyezer has joined #zuul | 18:27 | |
| pabelanger | tobiash: yah, we are hoping to start using it too, after zuul.o.o :) | 18:29 |
| *** electrofelix has quit IRC | 18:31 | |
| *** samccann has quit IRC | 19:14 | |
| *** pcaruana has quit IRC | 19:33 | |
| openstackgerrit | Merged openstack-infra/zuul master: Scope config line comments to change https://review.openstack.org/590446 | 19:37 |
| *** elyezer has quit IRC | 20:01 | |
| corvus | clarkb: can you review https://review.openstack.org/581754 pls? | 20:06 |
| corvus | tobiash: jhesketh has 2 questions on https://review.openstack.org/588201 i'm hoping you can respond and he'll +3 when he wakes up :) | 20:12 |
| tobiash | looking | 20:12 |
| *** elyezer has joined #zuul | 20:14 | |
| tobiash | responded, hope that are good answers | 20:17 |
| corvus | tobiash: makes sense to me | 20:17 |
| clarkb | corvus: looking | 20:17 |
| tobiash | :) | 20:17 |
| openstackgerrit | Merged openstack-infra/zuul master: Add winrm certificate handling https://review.openstack.org/535717 | 20:28 |
| openstackgerrit | Merged openstack-infra/zuul master: Support job pause https://review.openstack.org/585389 | 20:29 |
| pabelanger | yay | 20:29 |
| tobiash | clarkb: responded on 581754 | 20:30 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Add allowed-triggers and allowed-reporters tenant settings https://review.openstack.org/554082 | 20:31 |
| openstackgerrit | Logan V proposed openstack-infra/zuul master: encrypt_secret: Allow file scheme for public key https://review.openstack.org/581429 | 20:31 |
| corvus | tobiash, clarkb: i expect a nice long deprecation period for sighup. but i do think we should get rid of it eventually. | 20:32 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Add a yarn role https://review.openstack.org/586550 | 20:34 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Add command socket handler for full reconfiguration https://review.openstack.org/581754 | 20:36 |
| corvus | tobiash: i think i'm about convinced that https://review.openstack.org/590442 is the better way. you want to talk me out of it? | 20:36 |
| corvus | clarkb, mordred: do you have an opinion on 590429 vs 590442 ? | 20:36 |
| tobiash | corvus: actually you talked me out of it ;) | 20:37 |
| tobiash | corvus: but I see that's a valid compromise concerning system load | 20:37 |
| corvus | tobiash: i know, at the same time i talked me into it. :) i think perfect may be the enemy of good here. | 20:37 |
| tobiash | corvus: I think it's good enough | 20:37 |
| tobiash | tbh I didn't see any project yet that messes with the repo on localhost | 20:38 |
| tobiash | so that's imho a limitation I can perfectly live with | 20:38 |
| openstackgerrit | Merged openstack-infra/zuul master: Add request reference when hitting a node failure https://review.openstack.org/589856 | 20:43 |
| tobiash | clarkb: maybe you could add 580295 to your review queue? | 20:44 |
| tobiash | it's an easy one | 20:44 |
| mordred | corvus: I agree, I think messing with the localhost repo is unlikely for the sorts of things that are going to want line comments | 20:47 |
| clarkb | tobiash: sure, I'm juggling paperwork things and code reviews (it is benefits election time of year for me, something you probably don't do in germany) | 20:47 |
| clarkb | tobiash: thinking about that one, can we just not log that at all? (I'm not sure how useful it is when running as a github app) | 20:52 |
| openstackgerrit | Merged openstack-infra/zuul master: Allow get_mime: False on localhost https://review.openstack.org/549475 | 20:52 |
| *** ssbarnea has quit IRC | 20:52 | |
| *** gouthamr_away is now known as gouthamr | 20:53 | |
| tobiash | clarkb: when running as a github app with rate limit enabled (like it is enforced against github.com) it is a really useful logging | 20:54 |
| tobiash | clarkb: but not in our case with a ghe instance that doesn't do rate limiting | 20:54 |
| clarkb | tobiash: even when run as an app? I thought when you run as an app its a non issue | 20:54 |
| tobiash | clarkb: in that case you have a rate for every installation but you have a rate | 20:54 |
| clarkb | ah | 20:55 |
| clarkb | still applies then | 20:55 |
| tobiash | clarkb: so when running as an app it's a less issue but no non issue | 20:55 |
| clarkb | got it | 20:55 |
| openstackgerrit | Merged openstack-infra/zuul master: Use copy instead of symlink for multi-tenant dashboard https://review.openstack.org/587554 | 21:09 |
| openstackgerrit | Merged openstack-infra/zuul master: Make GitHub rate limit logging configurable https://review.openstack.org/580295 | 21:13 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-jobs master: [WIP] kerberos & afs client roles https://review.openstack.org/589334 | 21:19 |
| *** gouthamr is now known as gouthamr|brb | 21:20 | |
| *** gouthamr|brb is now known as gouthamr | 21:20 | |
| *** gouthamr is now known as gouthamr|brb | 21:21 | |
| openstackgerrit | Merged openstack-infra/zuul master: Add command socket handler for full reconfiguration https://review.openstack.org/581754 | 21:22 |
| mordred | corvus, tristanC: required_projects is a dict | 21:24 |
| mordred | so I think it's just missing a .values() in the for loop | 21:24 |
| mordred | otherwise we're iterating over the keys, which are strings | 21:25 |
| mordred | now - the real question is - why didnt the tests trigger that | 21:25 |
| corvus | mordred: agreed; i think we need a test (or an expanded test case) | 21:29 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-jobs master: [WIP] kerberos & afs client roles https://review.openstack.org/589334 | 21:33 |
| corvus | i need to see a github payload when a branch is created | 21:36 |
| corvus | should i just look for 40 '0' characters in the zuul-debug log? | 21:36 |
| mordred | corvus: you could tail the logs and go create a branch in a gtest repo? | 21:37 |
| mordred | I guess we probably don't log that - we could create a branch in a gtest repo and then go look at the webhook payload debug page? | 21:38 |
| corvus | mordred: i think we do log all the payload | 21:38 |
| mordred | corvus: neat | 21:38 |
| corvus | and it looks like we watch gtest-org/ansible so i'll go do that | 21:38 |
| * mordred is helping | 21:38 | |
| corvus | how do i make a new branch? | 21:40 |
| mordred | you click the branch button I think? | 21:40 |
| *** gouthamr|brb is now known as gouthamr | 21:40 | |
| corvus | that just lets me switch branches in the ui | 21:41 |
| mordred | corvus: hrm. maybe you just push a new branch? | 21:41 |
| corvus | is that how people do that in github? | 21:42 |
| mordred | corvus: yeah - https://github.com/gtest-org/ansible/settings/branches only has protection settings | 21:42 |
| mordred | corvus: I think so? | 21:42 |
| corvus | (i'm asking because the goal here isn't for me to create a branch, as such, but for me to create a branch in the way that normally happens in github so i can verify the test behavior :) | 21:42 |
| mordred | corvus: oh! | 21:42 |
| mordred | corvus: in the branch dropdown ... | 21:42 |
| mordred | "find or create branch" | 21:43 |
| mordred | corvus: so type the new name and it'll show you a create button | 21:43 |
| corvus | mordred: that is intuitive | 21:43 |
| mordred | corvus: very much so | 21:43 |
| mordred | corvus: it might be worthwhile checking both flows | 21:44 |
| corvus | mordred: agreed | 21:44 |
| mordred | corvus: I know when I'm sending in ansible PRs, I create branches in my ansible fork by pushing | 21:44 |
| clarkb | mordred: ya I think thats common for the PR use case | 21:48 |
| corvus | they behave similarly and everything checks out. thanks :) | 21:50 |
| mordred | yay! | 21:53 |
| *** tobasco is now known as tobias-urdin | 22:14 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP: cache branches in connections/sources https://review.openstack.org/589975 | 22:21 |
| *** elyezer has quit IRC | 22:54 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Cache branches in connections/sources https://review.openstack.org/589975 | 23:05 |
| *** elyezer has joined #zuul | 23:07 | |
| *** ssbarnea has joined #zuul | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!