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
signature.asc
Description: PGP signature
