Bold title to start the conversation and help with T317177.
The archiva1001 server might be a good candidate to move from public to private vlan and be fronted by the CDN. Using the squid proxies if external resources (eg. git) needs to be fetched from the Internet. The CDN brings also a layer of security with abuse control and rate limiting.
If deemed a good option (eg. no blockers) this could for example be bundled with the bullseye upgrade.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T317177 [tracking] Don't keep on the public vlans hosts that don't require it | |||
| Declined | None | T317182 Move archiva to private IPs + CDN |
+1
if external resources (eg. git) needs to be fetched from the Internet
JVM Dependencies are automatically fetched from the internet (maven central usually) and cached in our archiva.
Andrew don't we have also to allow git-fat binaries to be deployed on external clients? Or do I misremember? I don't see anything against moving forward but I am wondering if the git-fat workflow needs some extra care before moving to the CDN.
Oh hm. Yes. Well maybe. Scap uses git fat to pull artifacts via rsync from archiva. This should still work internally.
Errrr, I'm not certain about how the refinery artifact update Jenkins job works. I don't think it needs to run any git-fat push or pull commands. The artifacts are added to the git-fat repo by a cron job on archiva, and git-fat pulls are only needed during scap deployments. Adding the artifacts to git-fat should just be a regular git push of a text file to gerrit that points at the git-fat repo.
But sometimes, if CI/CD goes wrong, then we do manage the git-fat files locally. I think that all the real interactions are with gerrit though, so it will be okay. We don't allow git-fat pushes directly.
Ack! I was thinking also to when one tests stuff like refinery-source locally (on their laptop/workstation outside the WMF), IIRC it pulls directly from archiva.wikimedia.org? it should work via squid proxy anyway, but I wanted to explore all ideas since in the past we had an issue with it (IIRC). Anyway, it is probably very easy to spin up archiva-next.wikimedia.org (backed up by a non-public-ip config) and see how it goes :)
When testing analytics/refinery/source, it is all Archiva / maven API.
analytics/refinery is used for deployment in prod of .jar files pulled from archiva via git-fat rsync. Sometimes, users might want to be able to do git-fat pull locally, but I think that is rare enough that we might not need to.
Setting to high priority, as it will help not only with the bullseye upgrade, but also T323210
Given that Archiva isn't supported anymore, we will migrate away from it. Thus this ticket isn't needed anymore.