- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 10 2022
Oct 7 2022
I've tested with the ips closed to the apache ones (88.99.95.218 and 88.99.95.220) and we can reach them, so we are probably blocked somewhere in the apache's infra
Apparently we're blocked somewhere at hertzner:
% tcptraceroute downloads.apache.org Selected device vlan1300, address XXX, port 49995 for outgoing packets Tracing the path to downloads.apache.org (88.99.95.219) on TCP port 80 (http), 30 hops max 1 xxx 2 xxx 3 * * * 4 xe1-1-10-paris1-rtr-131.noc.renater.fr (193.51.177.106) 1.101 ms 1.038 ms 1.018 ms 5 renater-ias-geant-gw.par.fr.geant.net (83.97.89.9) 1.470 ms 1.343 ms 1.259 ms 6 ae5.mx1.gen.ch.geant.net (62.40.98.182) 18.107 ms 18.143 ms 17.893 ms 7 ae2.mx1.fra.de.geant.net (62.40.98.180) 17.804 ms 27.069 ms 18.987 ms 8 * * * 9 core24.fsn1.hetzner.com (213.239.252.42) 20.140 ms 20.348 ms 19.926 ms 10 ex9k1.dc1.fsn1.hetzner.com (213.239.245.234) 19.754 ms 19.677 ms 20.425 ms 11 * * * ...
After the operator was updated to 0.12.2, it was possible to upgrade kubernetes to 1.22.
It was done by changing the version in the azure portal:
Oct 6 2022
- fix the version number
- remove the command line in comment
Oct 5 2022
Looks like the gitlab operator is now compatible with kubernetes 1.22.
https://docs.gitlab.com/operator/installation.html#kubernetes
unfortunately it can't work without T4604 as the store is configured to use the letencrypt certificate:
Oct 4 2022
rebase
@KShivendu Any news regarding these profiling ?
Closing as there is no alerts since almost one month
regarding the last tests, we can start using it to battle proof its usage.
I found in several documentations where it's the tool recommended to manage load balancing on on-premise kubernetes deployments, for example: https://kubernetes.github.io/ingress-nginx/deploy/baremetal/#a-pure-software-solution-metallb
thanos exposed on the production cluster with this commit: rSPRE8fade05553ed4a01e54e1b8481150c0e055e3f34
Oct 3 2022
Oct 1 2022
Sep 30 2022
Sep 29 2022
Sep 28 2022
- Add monitoring of the internal service
Argo is now reachable on the internal network at https://argocd.internal.admin.swh.network/ but it uses an self-signed certificated
rebase
hum I completely forgot we'll have to think how to manage the ssl termination.
As is, there is not cert manager deployed on the cluster and I'm not sure we want to do it.
As metallb is configured, the internal domain can used the VIP
Sure there is (and it must have) nothing secret logged in the task.
Sep 27 2022
A new test with a node completely down, it seems it recover after ~5mn which looks related to some cache expiracy somewhere
Tue Sep 27 16:31:59 UTC 2022 60 bytes from 2e:81:20:19:02:4a (192.168.100.119): index=2926 time=1.679 msec Tue Sep 27 16:32:01 UTC 2022 Timeout Timeout Tue Sep 27 16:32:03 UTC 2022 ... Tue Sep 27 16:37:56 UTC 2022 Timeout Timeout Tue Sep 27 16:37:58 UTC 2022 60 bytes from 2e:84:a0:44:9e:c9 (192.168.100.119): index=2927 time=814.409 msec 60 bytes from 2e:84:a0:44:9e:c9 (192.168.100.119): index=2928 time=864.574 usec 60 bytes from 2e:84:a0:44:9e:c9 (192.168.100.119): index=2929 time=973.083 msec 60 bytes from 2e:84:a0:44:9e:c9 (192.168.100.119): index=2930 time=32.151 msec
If a node is drained out of the cluster, the rebalancing occurs in ~10s which it's what it's announced in the documentation
Tue Sep 27 16:17:21 UTC 2022 60 bytes from 2e:84:a0:44:9e:c9 (192.168.100.119): index=1985 time=1.710 msec 60 bytes from 2e:84:a0:44:9e:c9 (192.168.100.119): index=1986 time=1.376 msec Tue Sep 27 16:17:23 UTC 2022 Timeout Tue Sep 27 16:17:25 UTC 2022 Timeout Timeout Tue Sep 27 16:17:27 UTC 2022 Timeout Timeout Tue Sep 27 16:17:29 UTC 2022 Timeout Timeout Tue Sep 27 16:17:31 UTC 2022 Timeout Timeout Tue Sep 27 16:17:33 UTC 2022 Timeout Timeout 60 bytes from 2e:81:20:19:02:4a (192.168.100.119): index=1987 time=669.150 msec Tue Sep 27 16:17:35 UTC 2022 60 bytes from 2e:81:20:19:02:4a (192.168.100.119): index=1988 time=959.452 usec
With the ingress controller correctly configured and an ingress declared, everything seems to work correctly:
vsellier@pergamon ~ % cat test-ingress.txt GET /graphql/ HTTP/1.0 Host: archive.softwareheritage.org