|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "2019-11-05 Infrastructure Team Meeting" |
| 4 | +author: Pietro Albini |
| 5 | +team: the infrastructure team <https://www.rust-lang.org/governance/teams/operations#infra> |
| 6 | +--- |
| 7 | + |
| 8 | +Meeting run by shepmaster. Minutes written by pietroalbini. |
| 9 | +Attending: aidanhs, alexcrichton, kennytm, Mark-Simulacrum, pietroalbini, shepmaster |
| 10 | +[Start of the conversation](https://discordapp.com/channels/442252698964721669/443148319431065610/641335927721033732) |
| 11 | + |
| 12 | +## Removing MSYS2 ca-certificates workaround (P-high issue) |
| 13 | + |
| 14 | +A few weeks ago our CI broke due to a broken `ca-certificates` MSYS2 package, |
| 15 | +which caused all Windows builders to fail. The temporary patch was to install a |
| 16 | +vendored copy of that package, and since it’s not needed anymore pietroalbini |
| 17 | +landed a PR this week removing the hack from our CI configuration. |
| 18 | + |
| 19 | +The other part of the issue is figuring out whether to vendor MSYS2 and MinGW |
| 20 | +as a whole, but there is the issue of keeping the mirrors sort of up to date, |
| 21 | +and we don’t have a clear idea on how to fix that at the moment. We decided to |
| 22 | +downgrade the issue to P-medium and to talk about mirroring and vendoring at |
| 23 | +the All Hands 2020. In preparation of that meeting it will be useful to audit |
| 24 | +what we mirror at the moment and how old that is, but it’s not urgent and |
| 25 | +nobody has the time to work on it right now. |
| 26 | + |
| 27 | +## Figuring out data retention on Azure Pipelines (P-medium issue) |
| 28 | + |
| 29 | +This is not yet an issue, as the current retention is configured to 2 years. |
| 30 | +We’re waiting on some talks with Microsoft to settle before starting to poke |
| 31 | +people about this again. |
| 32 | + |
| 33 | +## Re-enable LLVM/debug assertions on slow builders (P-medium issue) |
| 34 | + |
| 35 | +We still don’t have the time budget to enable them back, but increasing the |
| 36 | +core count should allow us to do that. |
| 37 | + |
| 38 | +## New server for perf |
| 39 | + |
| 40 | +alexcrichton ordered an |
| 41 | +[AX41-NVMe](https://www.hetzner.com/dedicated-rootserver/ax41-nvme) bare metal |
| 42 | +server from Hetzner as a replacement benchmarking machine for perf, paid by |
| 43 | +Mozilla. We’re waiting on Hetzner to give us access to it before simulacrum can |
| 44 | +try it out and configure it. If we don’t get access in a few days alexcrichton |
| 45 | +is going to ping them. |
| 46 | + |
| 47 | +## Lifecycle policy for static.rust-lang.org |
| 48 | + |
| 49 | +static.rust-lang.org is backed by a S3 bucket, and since 2016 versioning is |
| 50 | +enabled on the bucket to prevent issues with accidental file deletions. Some of |
| 51 | +the files in that bucket are overridden each day though (for example nightly |
| 52 | +compilers), keeping a bunch of past versions stored. Those past versions are |
| 53 | +useless as there isn’t an easy way to get them from the CDN, and the files are |
| 54 | +also stored separately in other places on that bucket. Everyone agreed we |
| 55 | +should enable lifecycle policy to delete those useless files, and we reached a |
| 56 | +consensus on deleting them after three months. This won’t be noticeable by end |
| 57 | +users, installing old nightlies by date will still work. |
| 58 | + |
| 59 | +## What to do with the rust-lang-ci S3 bucket |
| 60 | + |
| 61 | +`rust-lang-ci` is a really old and currently unused S3 bucket which was used to |
| 62 | +store CI artifacts before we migrated them to `rust-lang-ci2`. There are still |
| 63 | +some files in there, so we enabled bucket logging for a month to see how |
| 64 | +frequent files there were accessed. |
| 65 | + |
| 66 | +Turns out, we had a total of 86 successful requests in a month, split between: |
| 67 | + |
| 68 | +- 69 requests were accessing cargo builds of 1.14.0 |
| 69 | +- 17 requests were accessing old CI mirrors |
| 70 | + |
| 71 | +Due to the low traffic we decided to remove those old CI mirrors, but for the |
| 72 | +cargo builds the question is more complicated. Due to a bug in the manifest |
| 73 | +generation back then, installing Rust 1.14.0 from rustup actually downloads |
| 74 | +Cargo from the bucket instead of the CDN, and removing those files would |
| 75 | +permanently break installing Rust 1.14.0. There was disagreement on whether to |
| 76 | +do that inside the team, and we reached the decision to wait until pietroalbini |
| 77 | +investigates whether redirects are feasible to configure in S3. |
| 78 | + |
| 79 | +## Early feedback on pietroalbini’s WIP ci-generate branch |
| 80 | + |
| 81 | +pietroalbini is working on a branch that implements a generator for our CI |
| 82 | +configuration, from a simplified custom DSL |
| 83 | +([branch](https://github.com/pietroalbini/rust/tree/ci-generate) - |
| 84 | +[documentation](https://github.com/pietroalbini/rust/tree/ci-generate/src/tools/generate-ci-config)). |
| 85 | +While the generator has a number of small benefits for us, the main driver |
| 86 | +between the creation of the branch is to work around some limitations in GitHub |
| 87 | +Actions’s configuration syntax, namely the lack of importable templates. There |
| 88 | +wasn’t time to properly discuss this so we deferred to next week. |
| 89 | + |
| 90 | +## Revisiting meeting run rotation |
| 91 | + |
| 92 | +A month ago we started rotating who runs the meetings, intending to revisit the |
| 93 | +decision today. The team felt either neutral or positive about the idea, so |
| 94 | +we’ll keep doing that for a while. aidanhs is going to run the next meeting. |
0 commit comments