On Wed, Aug 08, 2018 at 05:47:06PM -0400, Jimmy Kaplowitz wrote: > > No, the main reason it isolation. The builds take some global > > resources, loop devices, and may not return them in case of some errors. > > Google builds their official GCE Debian images inside transient GCE > instances, solely for isolation purposes (they use the Debian cloud team > build tools, probably still bootstrap-vz until we get FAI sufficiently > working). To be clear, nothing about that needs to be in GCE, except for > a few implementation details of their particular build harness. Regular > VMs work fine. At the Microsoft-hosted cloud sprint I proposed using cloud-provider VMs for builds targeting that provider. This is not because of any provider-specific behavior, but rather because the cloud providers provide all the isolation, resource management, and automation hooks that we could ask for. I still maintain that it's the better approach, but was told at the time that the builds need to happen on Debian-owned hardware, and that we had users specifically insisting on this. I'm not convinced by that argument, nor have I heard anything from AWS users expressing concern that the images are being built on AWS. Meanwhile I have been building all the AWS images using small (t2.micro), transient EC2 instances and a small shell script to handle the VM lifecycle and have managed to completely avoid the complexity of that giant whiteboard drawing from the sprint... https://salsa.debian.org/noahm/ec2-image-builder/blob/master/bin/launch-fai-builder.sh > I support the goal of isolation, but transient VMs can serve the same > purpose in a workflow that's more easily portable between casulana, > GitLab CI (I presume?), a personal dev laptop, and anywhere else one > might want to reproduce the flow. Which seems like a win for maximizing > how easy it is for people to hack on this - and also for companies like > Google to converge further with us on tooling. Indeed. Some time ago, I posted on my blog about how users can use our build tooling to generate their own custom AMIs that derive from our FAI configs. The workflow is identical, because it uses common infrastructure. A build process that relies on custom Debian infrastructure is not going to be useful to users, meaning they'll have to use a different workflow to build images, with different bugs, edge cases, failure modes, etc. (Note that the post was written before the above mentioned small shell script was written, so there are more steps. I should update that post...) https://noah.meyerhans.us/blog/2017/02/10/using-fai-to-customize-and-build-your-own-cloud-images/ noah
Attachment:
signature.asc
Description: PGP signature