Migrate rust-lang-ci bucket to us-west-1

[alexcrichton]

To reasons to do this:

• us-east-1, the current location of this bucket, tends to be the most frequent region to experience service outages.
• rust-central-station is located in us-west-1, so right now we're publishing artifacts from across the country.

AFAIK this isn't just a switch we can flip, so I suspect the migration path will look like:

• Create a new bucket. Probably rust-lang-ci2. Make sure it's in us-west-1
• Turn on replication of rust-lang-ci2, set it to replicate to rust-lang-ci.
• Update Travis/AppVeyor to publish to rust-lang-ci2
  • This should transitively publish to rust-lang-ci based on replication
• Update rust-central-station to pull from rust-lang-ci2
• Migrate all existing data in rust-lang-ci to rust-lang-ci2 -- not sure how to do this, I've heard there's a "COPY operation"
• Delete the rust-lang-ci bucket
• Help fix clients that are now broken.
  • Preliminary list: Rustbuild, Servo, bisect-rust.

[alexcrichton]

cc @aidanhs

[aidanhs]

clients that are now broken.

Also rustup - https://github.com/rust-lang-nursery/rustup.rs/blob/a11c01e8c07f02a189c2d1c824b968bc2a935036/appveyor.yml#L37

Delete the rust-lang-ci bucket

Hmm. This will also break the ability to build some old versions of Rust yourself. I think it's at least worth doing the thought experiment to consider leaving that bucket stagnant but still available. Maybe if hosting old builds in two places is excessively expensive, we just don't copy them across? Not sure what the best approach is.

Edit: then again, when we were using the centos 5 packages and they went away, that broke our ability to build older versions of rust with the docker images - maybe it's not a big deal.

If we do decide to delete part/all, I'd like to at least propose a deprecation period (say 1 stable release?) where we announce on irlo/reddit/wherever so packagers (or other people) using artifacts can move over. Note I'm just suggesting this out of courtesy - the artifacts are in a bucket called rust-lang-ci, so projects not under the rust-lang umbrella shouldn't expect them to always be available :)

[alexcrichton]

Yeah I don't think we can really provide a guarantee that our CI infrastructure always works, no only with centos 5 going away but other things like eventually ubuntu 16.04 will be out of date etc. I think the important part is checking out the repo and getting the same source, but building is sort of left up to the user.

And yeah I assumed we were going to delete for cost reasons, the rust-lang-ci bucket isn't exactly small... Although this may also be a great point to set forth a policy about deletion of old artifacts. Our "ever growing" bucket is static.rust-lang.org, and I think we'd rather not have two. How about:

• Don't delete rust-lang-ci for 30 days (or 2 cycles)
• rust-lang-ci2 policy is:
  • rust-ci-mirror is permanent
  • cargo-builds is getting entirely deleted (no one should use this any more)
  • rustc-builds-try - deleted after 30 days
  • rustc-builds-alt - not sure what to do here. If servo updates at least once every 30 days we could delete 30 day old builds. Depend on what they do.
  • rustc-builds - maybe deleted after 90 days?

[est31]

I wasn't able to find any previous discussion on the deletion policy issue. My main issue concerns bisecting past regressions, and I think deletion of stuff from rustc-builds after 90 days is a bit too short. There is definitely interest in regressions from more than 90 days ago... See this bug for example.

I think the limit should be raised to 6 months, that is 180 days, or maybe even a year. Regarding size concerns: we could adopt courgette which operates on diffs. E.g. only each "nightly build" would be stored completely, and the following builds would be stored as diffs from that build. Of course one has to implement this first but I think with this change one can achieve a quite remarkable decrease in required storage space, that can allow us to store the fine builds for a much longer time than 90 days.

[alexcrichton]

I believe this is all done now, so closing.