| opendevreview | Ian Wienand proposed openstack/project-config master: nodepool: Add Fedora 36 https://review.opendev.org/c/openstack/project-config/+/853893 | 01:26 |
|---|---|---|
| opendevreview | Ian Wienand proposed openstack/project-config master: nodepool: add rocky-9 stub https://review.opendev.org/c/openstack/project-config/+/853894 | 01:26 |
| ianw | i requested a fresh rocky-9 build | 01:51 |
| opendevreview | Merged openstack/project-config master: nodepool: Add Fedora 36 https://review.opendev.org/c/openstack/project-config/+/853893 | 02:02 |
| *** soniya29 is now known as soniya29|ruck | 03:39 | |
| *** soniya29 is now known as soniya29|ruck | 04:29 | |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: Fedora : update to Fedora 36 release nodes https://review.opendev.org/c/zuul/zuul-jobs/+/853909 | 04:37 |
| *** ysandeep|PTO is now known as ysandeep | 04:38 | |
| *** soniya29|ruck is now known as soniya29|ruck|afk | 05:06 | |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: zuul-jobs-test-ensure-python-pyenv: update matchers https://review.opendev.org/c/zuul/zuul-jobs/+/853913 | 05:16 |
| *** ysandeep is now known as ysandeep|afk | 05:18 | |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: zuul-jobs-test-ensure-python-pyenv: update matchers https://review.opendev.org/c/zuul/zuul-jobs/+/853913 | 05:27 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: Fedora : update to Fedora 36 release nodes https://review.opendev.org/c/zuul/zuul-jobs/+/853909 | 05:27 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: [wip] zuul-jobs-test-registry-buildset-registry-openshift-docker: use 9-stream https://review.opendev.org/c/zuul/zuul-jobs/+/853916 | 05:27 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: [wip] zuul-jobs-test-registry-buildset-registry-openshift-docker: use 9-stream https://review.opendev.org/c/zuul/zuul-jobs/+/853916 | 05:45 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: zuul-jobs-test-registry-buildset-registry : update matcher https://review.opendev.org/c/zuul/zuul-jobs/+/853918 | 05:45 |
| *** soniya is now known as soniya29|ruck | 05:57 | |
| mnasiadka | ianw: I can confirm rockylinux-9 nodes work, thanks for fixing that :) | 06:45 |
| *** soniya29|ruck is now known as soniya29|ruck|lunch | 07:31 | |
| *** jpena|off is now known as jpena | 07:36 | |
| *** soniya29|ruck|lunch is now known as soniya29|ruck | 08:38 | |
| *** ysandeep|afk is now known as ysandeep | 08:55 | |
| *** soniya is now known as soniya|ruck | 09:08 | |
| *** soniya|ruck is now known as soniya|ruck|afk | 09:24 | |
| *** efoley_ is now known as efoley | 09:35 | |
| opendevreview | Tobias Rydberg proposed opendev/irc-meetings master: Restart of the Public Cloud SIG https://review.opendev.org/c/opendev/irc-meetings/+/853938 | 09:54 |
| *** soniya|ruck|afk is now known as soniya|ruck | 10:18 | |
| *** rlandy__ is now known as rlandy | 10:22 | |
| ianw | mnasiadka: oh good, thanks for confirming :) | 10:50 |
| *** soniya is now known as soniya|ruck | 11:11 | |
| *** dviroel|out is now known as dviroel|rover | 11:28 | |
| *** ysandeep is now known as ysandeep|afk | 12:22 | |
| priteau | Hello. Do you know when https://review.opendev.org/c/openstack/project-config/+/853003 will get deployed to Zuul? It doesn't seem to be in place as https://review.opendev.org/c/openstack/kayobe/+/850903 still doesn't run CI jobs. | 12:48 |
| fungi | priteau: that change rolled out 5 days ago | 13:12 |
| frickler | 2022-08-22 12:46:06,340 ERROR zuul.GithubConnection.GithubClientManager: No installation ID available for project stackhpc/ansible-role-os-images | 13:13 |
| frickler | fungi: priteau: does the zuul app need to be added to that repo? | 13:13 |
| fungi | oh, good question. i don't actually know much about how the github driver works | 13:14 |
| fungi | there were other repos from the same org already in the config, so i guess i just assumed that was an org-wide thing | 13:15 |
| frickler | ah, no: | 13:15 |
| frickler | 2022-08-22 12:46:17,717 ERROR zuul.source.GithubSource: Failed to retrieve dependency https://github.com/stackhpc/ansible-role-os-images/pull/63. Retrying | 13:15 |
| frickler | priteau: that PR has been merged, iiuc it can no longer be reference as a dependency then | 13:15 |
| frickler | admittedly it would also be helpful if zuul reported that error in gerrit instead of only in its log | 13:18 |
| fungi | i also wasn't aware zuul didn't allow merged pull requests as cross-project dependencies, but as i said i'm not all that familiar with the github driver so i guess that could be the case | 13:18 |
| frickler | fungi: I think the root cause for the issue might be that github deletes the source branch after the merge, so zuul fails at cloning it | 13:20 |
| frickler | not sure if we'd want to teach the zuul github driver to just ignore the dependency for merged PRs and use the target branch instead | 13:21 |
| fungi | yeah, i did see the source branch deletion message in the pr comments, but as far as internals of the driver didn't realize that's what it pulled rather than the discrete commits from the pr | 13:21 |
| priteau | OK, so we need to update the change and remove the depends-on | 13:22 |
| fungi | i guess the problem there is that the merged state of the pr may not actually include the parent commits if gh is auto-rebasing instead of creating merge commits | 13:23 |
| fungi | perhaps the driver could be made to try to git am the patch from e.g. https://patch-diff.githubusercontent.com/raw/stackhpc/ansible-role-os-images/pull/63.patch | 13:25 |
| priteau | Thanks, the updated change is running CI jobs now. | 13:26 |
| fungi | priteau: it would probably still be good to find out if a dependency on an open pr for one of those added projects works | 13:27 |
| fungi | just to make sure that was the issue | 13:27 |
| priteau | I've pushed another change to test | 13:30 |
| priteau | I don't see Zuul running jobs for it | 13:32 |
| priteau | https://review.opendev.org/c/openstack/kayobe/+/853979 | 13:33 |
| frickler | priteau: yep, still the same pair of errors. together with the surrounding logs, the missing zuul app seems to be the culprit | 13:42 |
| priteau | OK, I will check what can be done on our side | 13:43 |
| priteau | mgoddard: is this something you are managing? | 13:43 |
| Clark[m] | The GitHub app shouldn't be required from depends on from our side. The app is only needed to have GitHub events drive zuul | 13:53 |
| Clark[m] | Deleting the branch that hosted the PR does break things. GitHub prunes the refs and shas when you do that so zuul can't fetch the information. I don't know what the updated change with the updated depends on isn't working | 13:55 |
| priteau | Is there an error in logs like there was for the previous patch? | 13:59 |
| Clark[m] | I think frickler said it was the same error. I can't check myself for another hour or so. Just wanted to call out the app should only be required to drive zuul from the GitHub side which isn't what is being done here | 14:00 |
| *** ysandeep|afk is now known as ysandeep | 14:01 | |
| *** dasm|off is now known as dasm | 14:02 | |
| priteau | OK. But the branch still exists in this case. | 14:05 |
| frickler | Clark[m]: priteau: this is the whole log I found https://paste.opendev.org/show/bhgxMh429jLp4NzTU4X1/ , this then repeats a couple of times | 14:06 |
| Clark[m] | Did the zuul GitHub driver update recently to assume an app is always installed? | 14:10 |
| Clark[m] | I think the flow is: zuul finds depends on, maps to GitHub driver, looks for app install and fails to find one, the manually contracts the information needed to satisfy the depends on. I'm not sure those errors are fatal. | 14:21 |
| Clark[m] | Line 43 of the paste indicates it got the PR as well. | 14:22 |
| frickler | might well be a bug in zuul triggered by those PRs. like maybe the "Merging is blocked - Merging can be performed automatically with 1 approving review." which is rather non-standard | 14:37 |
| frickler | so whatever triggers this, IMO there should be a check for commit==None here https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/github/graphql/__init__.py#L126-L129 | 14:51 |
| clarkb | is there a traceback failing on a None type not having attributes/methods? | 14:54 |
| *** dviroel|rover is now known as dviroel|rover|lunch | 14:58 | |
| *** soniya|ruck is now known as soniya|out | 15:05 | |
| clarkb | oh I see the graphql request is a 401 | 15:12 |
| clarkb | I agree I think this is exposing a bug in zuul | 15:13 |
| * clarkb works on an updated paste | 15:13 | |
| *** ysandeep is now known as ysandeep|dinner | 15:13 | |
| clarkb | I've posted details to the zuul matrix room | 15:16 |
| clarkb | as I don't think thsi is an opendev problem but a zuul one | 15:16 |
| clarkb | infra-root landing https://review.opendev.org/c/opendev/system-config/+/853528 is on my todo list. Any objections to me approving that now and then trying to restart gerrit sometime later today? I know the openstack release is approaching so trying to be extra careful but I expect a change like this should be quite safe? | 15:40 |
| clarkb | Gitea 1.17.1 is out now too. https://review.opendev.org/c/opendev/system-config/+/847204 may be worth reviewing now then we can figure out when a good time to land and upgrade gitea is | 15:41 |
| corvus | clarkb: ++ | 15:42 |
| fungi | clarkb: gerrit restart today sounds great, thanks! | 15:51 |
| clarkb | great change approved | 15:52 |
| fungi | thanks! | 15:53 |
| *** dviroel|rover|lunch is now known as dviroel|rover | 16:12 | |
| clarkb | fungi: also do you think you'll have time this week to poke at mm3 further? I've got a node held currently for the latest patchset (198.72.124.71) | 16:22 |
| clarkb | tuesday's tend to be full of meetings and I'm out wednesday. I can probably dig into that with you on thursday if you want me to help (I've definitely learned a few things about mm3 at this point) | 16:22 |
| fungi | yeah, hopefully wednesday and thursday we can test some production-like config/archive migrations. today i'm still trying to catch up from vacation, tomorrow is solid meetings as you noted, and friday's a bust since i've got to take christine to an appointment on the mainland | 16:26 |
| *** tkajinam is now known as tkajinam|off | 16:35 | |
| *** jpena is now known as jpena|off | 16:38 | |
| clarkb | frickler: priteau: one thing I notice browsing that PR while logged in is that the stackhpc/ansible code owner isn't clickable like jovial is | 16:39 |
| clarkb | I wonder if we don't have perms to see that user and the graphql query does seem to try and list that sort of info? | 16:39 |
| clarkb | If I look at a random ansible proper change with a reviewer listed the reviewer is clickable there | 16:40 |
| clarkb | also the user appears to be 'stackhpc/ansible' which is also a valid repo path. Maybe graphql is getting confused due tocollisions? | 16:41 |
| priteau | That's because it's a private team in our org | 16:42 |
| priteau | I can update the change to use an older, unmerged PR with users as reviewers | 16:42 |
| clarkb | that seems like the liekly issue then | 16:42 |
| clarkb | zuul is trying to list code review requirements and getting a not authorized error because stackhpc/ansible is hidden away is my hunch | 16:42 |
| clarkb | I think zuul could report this issue better, but I'm not sure zuul can work around it in a reasonable way. It would still be an error I thinik | 16:43 |
| priteau | I've updated the change to depend on https://github.com/stackhpc/ansible-role-os-images/pull/44, but it still doesn't run jobs | 16:44 |
| priteau | Unless it is still getting our new code review requirement from the API | 16:44 |
| clarkb | looks like it is still getting a 401 from github | 16:46 |
| clarkb | [e: f023a8f7b3c740658dd1e01f89d21e4c] POST https://api.github.com/graphql result: 401, size: 177, duration: 55, zuul_query: canmerge, owner: stackhpc, repo: ansible-role-os-images, pull: 44, head_sha: 33ce0bc07293900073c887b135706863488d46d2 | 16:47 |
| clarkb | maybe that rules out the code reviewer isn't visible idea. Something else is tripping authorization issues? | 16:47 |
| clarkb | https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/github/graphql/canmerge.graphql is the query executed. I don't know enough about github's permission model to say why this does/doesn't work | 16:48 |
| clarkb | it does seem to be repo specific though. And whatever the issue is I'm not sure zuul will be able to work around it, just get better at reporting the error (will depend on whether or not zuul can function without the resulting data if we can update the query to dodge problematic access) | 16:49 |
| priteau | And adding the zuul app to the repo, as was suggested. Could it help? | 16:49 |
| clarkb | It may help if that gives zuul the necessary permissions in your repo to complete that query | 16:49 |
| clarkb | my understanding is that the app really should only be required if taking action on github events and/or trying to merge changes with zuul. | 16:50 |
| clarkb | Otherwise the expectation (and what seems to work with say ansible/ansible and a few ohter repos) is that we can fetch sufficient info via the api to integrate with those upstreams via downstream events | 16:50 |
| priteau | We can try and see if that makes a difference. | 16:50 |
| priteau | Thanks for investigating. | 16:51 |
| clarkb | If I open the PR in an unauthenticated context then the checks info goes away. I thought zuul was making these requests with a token so it is authenticated. But maybe it isn't when there isn't an app and checks info is hidden? | 16:53 |
| clarkb | corvus: ^ do you know who might understand the permissions model of all this better? perhaps someone at bmw? | 16:54 |
| *** ysandeep|dinner is now known as ysandeep|out | 16:57 | |
| opendevreview | Merged opendev/system-config master: Increase the number of Gerrit threads for http requests https://review.opendev.org/c/opendev/system-config/+/853528 | 16:58 |
| corvus | clarkb: maybe try asking in #zuul again in a few weeks? lots of folks on vacation. | 17:01 |
| clarkb | I'm reading the githubconnection.py file in particular how it handles clients and now I'm beginning to wonder if I've misunderstood when the app is necessary. We've told people they don't need the app for including the repo in their jobs as a required project (and I believe tripleo uses thsi successfully for a number of ansible roles/collections) | 17:11 |
| clarkb | But in the getGithubClient() method which is used by fetch_canmerge() to get a client (and that is used to satisfy a depends on) it seems to think if there is an app id then the app should be installed to the project and we use that for auth | 17:12 |
| clarkb | so the fix here may be to add zuul to the project repo and annotate in my head that only reuqired projects but not depends on function without the app | 17:12 |
| corvus | i think we would like depends-on to work without app installation, so i think changes that help achieve that would be welcome | 17:13 |
| clarkb | that method also has a comment that seems to say we will fallback to anonymous | 17:14 |
| clarkb | anonymous PR GETs seem to have all the info there except for the checks info. I wonder if we can better support depends on here if we only request checks info when zuul needs it then maybe we can anonymously fetch the PR info? | 17:15 |
| clarkb | I'll try to bring this up with the BMW folks when vacations end | 17:15 |
| fungi | clarkb: anonymous api calls get slotted into a different rate limit, so could be problematic for that reason | 17:17 |
| fungi | or at least that was my recollection for why it got updated to prefer authenticated calls whenever possible | 17:17 |
| clarkb | fungi: thats true, but getting rate limited is better than a 401 since it won't happen all the time | 17:17 |
| clarkb | in cases like this I suspect depends on to github are infrequent enough to limit the impact of rate limits. And when we do hit them we can suggest using a different code hosting platform :) | 17:18 |
| fungi | i assumed there were a lot more that wouldn't need checks info than just depends-on, but maybe not | 17:19 |
| clarkb | fungi: I think if zuul is acting as the CI system for a github repo then it always needs the checks info since it is updating it | 17:20 |
| fungi | though it could also be a fallback path for 401 results | 17:20 |
| clarkb | and if zuul isn't acting as the CI system I think required projects and depends on are the integration points? separately it is crazy to me that you must authenticate to see checks info | 17:21 |
| fungi | but at any rate, more on-topic for the zuul matrix channel i guess | 17:21 |
| *** rcastillo|rover is now known as rcastillo | 18:22 | |
| *** pojadhav is now known as pojadhav|out | 18:23 | |
| danielo | Greetings. Since about Wednesday of last week, all traffic to the opendev/openstack gerrit from just one of my external IP addresses appears to be blocked. What's the best way to see about seeing if that is the case, and if so, clearing the block? | 19:27 |
| clarkb | danielo: a couple (what I think anyway) jenkins servers were blocked because they appeared to be improperly configured to request a gerrit event log | 19:41 |
| clarkb | danielo: I'm guessing one or both of those are yours? | 19:41 |
| clarkb | if we can address the noisy requests that 404 indefinitely (and will continue to do so) then I think we can open that back up again | 19:42 |
| danielo | Possibly; I'm just the network engineer, but I believe it is a Jenkins server. | 19:42 |
| clarkb | the requests are to /plugins/events-log/ and are performed by apache httpclient running on java 8 | 19:43 |
| danielo | OK, thanks. What can I tell the admins they need to do to get back in good graces? | 19:43 |
| danielo | Great. I'll check with the admins and see if that is something they're doing. | 19:44 |
| clarkb | I think we can ask them to update their jenkis configuration to stop perpetually making requests that will 404. We're happy to have them use the ssh event stream. | 19:44 |
| clarkb | We may have felt more confident blocking the IP due to the failed requests (without double checking there weren't also valid requests). It was done in response to some load issues and we were trying to mitigate where we could | 19:47 |
| danielo | Makes sense | 19:48 |
| clarkb | infra-root anything else to add to tomorrow's meeting agenda? | 20:46 |
| fungi | i have nothing | 20:46 |
| corvus | clarkb: 1 sec | 20:48 |
| corvus | clarkb: i added an item to https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting thxn for the ping | 20:52 |
| clarkb | you're welcome I see it too so it'll get included | 20:52 |
| clarkb | The gerrit config update applied (I just double checked the server). In the past ianw has often volunteered to do them when things are quiet. I'll see if ianw wants to do that this time otherwise I'll plan to do it before my day ends | 21:27 |
| fungi | i'll probably be around fairly late in my day too | 21:40 |
| danielo | clarkb: The admins claim they are using the Gerrit Trigger plugin with the recommended configuration at https://docs.opendev.org/opendev/system-config/latest/third_party.html#the-jenkins-gerrit-trigger-plugin-way . That said, according to the plugin's docs it has a feature that checks that URL to see if the server has the events-log plugin installed (see https://plugins.jenkins.io/gerrit-trigger/#plugin-content-missed-events-playback | 21:51 |
| *** dasm is now known as dasm|off | 21:51 | |
| clarkb | danielo: any chance they can communicate with us? I don't know that we need to play telephone | 21:51 |
| danielo | clarkb: I was thinking the same think. What's the best way to get them in touch? IRC? | 21:52 |
| clarkb | ya synchronous comms here on IRC. Or they can subscribe to our mailing list service-discuss@lists.opendev.org here https://lists.opendev.org/cgi-bin/mailman/listinfo/service-discuss and use email asynchronously | 21:53 |
| *** dviroel|rover is now known as dviroel|out | 21:53 | |
| clarkb | I guess https://plugins.jenkins.io/gerrit-trigger/#plugin-content-gerrit-server-events-log-plugin is the part of the plugin that is giving us trouble. Unfortunately that doesn't indicate if we can disable it | 21:54 |
| clarkb | I think we can probably go ahead and remove the blockage, but it would be good to better understand why jenkins is so spammy now | 21:55 |
| danielo | Looks like you can if you disable the REST API... but that might have other ramifications. | 21:55 |
| danielo | That is, disable the REST API from the gerrit trigger plugin | 21:56 |
| danielo | Do you still want me to have the admins reach out to you? | 21:56 |
| clarkb | danielo: I think it would be good for them to know how if they are going to talk to these services. I'm not sure it is urgent here. More that game of telephone is inefficient | 21:57 |
| clarkb | fungi: do you see where in the iptables rules frickler made these drops? I'm not seeing them myself | 21:58 |
| clarkb | I guess it must be the very first rule | 21:59 |
| clarkb | I'll just restart the netfilter persistent service which should reapply our normal ruleset | 22:00 |
| clarkb | danielo: thats been done if you want to have them double check things are happy again | 22:02 |
| danielo | clarkb: checking... | 22:02 |
| clarkb | infra-root: side note restarting netfilter-persistent has a side effect of blowing away the docker chains. This doesn't (currently) affect us because we use host networking | 22:03 |
| clarkb | infra-root: but that is something we should be aware of should we ever stop using host networking exclusively for containers | 22:03 |
| danielo | clarkb: still no responses to Gerrit SSH (29418/tcp), HTTPS (443/tcp) or ping from that source address. If it helps, I can give you my last octet. | 22:10 |
| clarkb | danielo: ya we should probably double hceck the addrs. But I reset our entire set of iptables rules so ther eshouldn't be anything on our side blocking you now | 22:11 |
| clarkb | and I've just double checked that the port is generally open from my location (so there isn't some widespread issue) | 22:13 |
| ianw | i'm happy to do a gerrit restart later | 22:16 |
| clarkb | ianw: thanks | 22:16 |
| clarkb | danielo: manual testing can be done via something like `ssh -p 29418 yourusername@review.opendev.org gerrit ls-projects` this should print a couple thousand lines of text containing the repo names in the gerrit server | 22:17 |
| danielo | clarkb: last octet is 21; it works from other addresses in the same prefix | 22:18 |
| clarkb | ok the one in the rule we had ended in a 5. However, in our logs discussing this back on wednesday there was a .21 mentioned. So now I'm wondering how frickler updated the fules | 22:20 |
| clarkb | s/fules/rules/ | 22:21 |
| clarkb | fungi: ianw ^ ideas? | 22:21 |
| * clarkb attempts to check security group rules out of completeness | 22:21 | |
| ianw | hrm, i imagine it would only be iptables, confirmed it looks clear to me | 22:23 |
| clarkb | security groups appear clear too if I'm reading things correctly | 22:24 |
| clarkb | unfortunately frickler didn't specify how things were blocked | 22:25 |
| ianw | tcp dpt:29418 flags:FIN,SYN,RST,ACK/SYN #conn src/32 is the connection limit rule right? | 22:25 |
| clarkb | ianw: yes | 22:25 |
| ianw | seems to be the only thing it might have hit | 22:26 |
| clarkb | apache isn't at play here since it is port 29418 and ansible would've reset that anyway | 22:27 |
| fungi | and the connection limit overflow is only for too many concurrent connections (like 100) | 22:28 |
| clarkb | neutron's firewall as a service doesn't seem present in that cloud so no rules there | 22:29 |
| corvus | clarkb: `ip route` | 22:31 |
| fungi | oh! | 22:32 |
| fungi | indeed, there are a ton of blackhole entries in the routing tabke | 22:32 |
| fungi | table | 22:32 |
| clarkb | oh wow | 22:32 |
| clarkb | frickler: ^ can we pleaas use the firewall to drop packets | 22:32 |
| *** rlandy is now known as rlandy|out | 22:32 | |
| clarkb | I think for me at least thats far more intuitive since that is the job of a firewall | 22:32 |
| fungi | so anyway, we should be able to ip ro del those | 22:33 |
| clarkb | fungi: thanks /me is pulling up manpages now | 22:34 |
| corvus | i think if the pattern holds, probably `ip route del blackhole A.B.C.D` or `ip route del blackhole A.B.C.0/24` depending on the rule | 22:35 |
| clarkb | fungi: looks like `ip route delete blackhole ipspecifier` ? | 22:35 |
| clarkb | corvus: yup thats what I just concluded reading the manpage too | 22:36 |
| clarkb | fungi: ^ if you agree I can run that for the ip in question | 22:36 |
| fungi | yeah, or may be able to just get away with ip ro del a.b.c.d/e | 22:36 |
| clarkb | cool trying that now | 22:36 |
| fungi | usually the destination is enough to identify the route | 22:36 |
| clarkb | ok thats done seems to have removed it | 22:37 |
| clarkb | danielo: ^ if you want to try again | 22:37 |
| danielo | clarkb: It's alive! Thank you for your help today. | 22:37 |
| clarkb | we can followup with frickler on cleaning up the other routes tomorrow. In general I have a preference myself for using the firewall to drop packets since in my head that is the job of a firewall and not a router. But I'm open to using the route table for this and learning to check it in the future if people prefer it | 22:38 |
| clarkb | I suspect it is slightly cheaper to use the route table which may be one reason to prefer it (but linux network is complicated enough this may not be true) | 22:39 |
| corvus | the routing table is counter-intuitive for me as well; i would have expected iptables. | 22:39 |
| fungi | the problem with blackhole routing return paths is that i don't think iptables/netfilter is smart enough to factor urpf into its filtering decisions, so lets the initiating packets in and starts socket negotiation and adds state table entries | 22:42 |
| clarkb | fungi: but if we block with iptables then iptables is aware of the whole decision making chain and can manage the state properly? | 22:43 |
| fungi | yes, well telling packet filtering to block the first incoming packet means it never gets far enough to create state table entries nor start socket negotiations which will never complete | 22:44 |
| corvus | ++ | 22:44 |
| fungi | blackhole routing is analogous to egress filtering | 22:45 |
| fungi | so in that sense, for these sorts of situations, ingress filtering seems preferable | 22:45 |
| fungi | we could set up source route blackholing too i think, which would be more akin to ingress filtering, problem there is order of operations. iptables is hooking a bpf (i think? this may have changed more recently in kernel land) so sees the packets before they reach the routing table to get discarded by any source routing rules | 22:47 |
| fungi | typically, ingress filters are the first thing to see incoming packets, and egress filters are the last thing to see outgoing packets. routing happens after ingress filtering and before egress filtering | 22:48 |
| clarkb | separately https://issues.jenkins.io/browse/JENKINS-69338? appears to be the issue tracker for the gerrit trigger plugin | 22:50 |
| clarkb | er https://issues.jenkins.io/browse/JENKINS-69338?jql=resolution%20is%20EMPTY%20and%20component%3D15731 | 22:50 |
| clarkb | I think I have an account on this server | 22:53 |
| clarkb | oh looks like they also use the github repo issue tracker | 22:54 |
| clarkb | oh wait no thats a sub library that they have upstream of them | 22:57 |
| clarkb | danielo: I've discovered that you can modify the check period in the plugin: Long.getLong("com.sonyericsson.hudson.plugins.gerrit.trigger.playback.checkEnabledPeriod" | 23:00 |
| clarkb | danielo: the default is 2ms (I don't know why 2ms was chosen) but maybe ya'll could set that to something like once a week? It is very unlikely we'll add that plugin any time soon | 23:01 |
| clarkb | though digging around through the source I'm not sure where you are supposed to set that value. It may jus always fail to find it and use the default? That would be unfortunate | 23:05 |
| clarkb | I'm assuming there must be some configuration field that you can edit that into. Maybe it has to go directly into some xml and isn't exposed via the web? Its been a long time since I used jenkins and not sur ewhat the current method for doing that is | 23:08 |
| clarkb | oh have I misread that and its is actually 2 seconds but carried as a millisecond value? In any case checking every 2 seconds if a plugin has been installed to a gerrit server isnt much better than every 2ms | 23:14 |
| clarkb | it should check on the order of days by default imo. Its not like plugins are installed and removed from gerrit servers frequently | 23:14 |
| danielo | clarkb: That is excessive. I'll ask the admins to see if they can figure out a way to reduce the frequency. If they do, I'll ask them to share it with you so you can update the Sphinx docs. | 23:15 |
| clarkb | danielo: that would be excellent, thank you | 23:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!