(Disclosure: I'm employed by AWS, and generally a fan of it, but am not speaking in any official capacity on its behalf. Never the less, you may want to consider the possibility that my position is biased.) On Thu, Mar 17, 2022 at 12:03:18PM +0100, Julien Cristau wrote: > DSA's looking into options to replace some of our archive mirroring > infrastructure. For context, so far we've been maintaining a few machines > around the globe, called syncproxies, that serve as "hubs" for archive > mirroring and push downstream mirrors. > As some of that hardware ages we're looking at other options, including > using cloud, to reduce the maintenance burden and make things a bit more > flexible. The syncproxy hosts store the archive and are used as rsync sources by the mirror network, correct? Inbound syncs from ftp-master (?) are also done by rsync? Geographic diversity is a desirable trait in order to support the global nature of the mirror network, correct? How much inbound and outbound bandwidth do they typically consume? How much local storage? > Would it be possible to work with the cloud team to stand up appropriate > accounts and so on on one of the cloud infras Debian has a relationship > with? I don't have a whole lot of knowledge of this space so will > probably end up asking a bunch of stupid questions. Any of the cloud services with which we work should be able to provide the services you need. On AWS, where the cloud-team's footprint is most mature, we have a number of SPI owned accounts and the technical details of providing the resources you need would be fairly straightforward to work out, although there are some outstanding questions around individual user authentication to the service console and APIs. The bigger details to work out relate to the sponsorship agreement we have with them and whether this is covered by it. I'll poke around internally and see about getting clarification. > (One possibly complicating factor is there's some element of sensitivity > because these machines host embargoed binaries for the security > archive.) Ack. I think this is something we can manage, but we'll need to be explicit about how we do so. We'll deal with this sort of detail when we've got some administrivia worked out. noah
Attachment:
signature.asc
Description: PGP signature