Hi Thomas, Thank you for the idea, however, after looking at it, I see FAI as technology akin to KickStart, MAAS, AutoYast, etc.
With FAI, I can see a problem with having Cloud-specific classes (e.g. Azure, Google, Azure, DigitalOcean, et al) in that we would essentially re-create Cloud-init's data-sources. Knowing which cloud an instance is on is non-trivial (for example, Alibaba uses CPU ID, AWS machine UUID, Azure DHCP options, DigitalOcean SMBIOS, OpenStack CDROM, etc). Merely detecting the cloud and then translating cloud-specific meta-data into a common language has been a continual headache for the cloud-init maintainers. And as someone who has written a few of the cloud-init data-sources, I can tell you first hand that re-creating them in bash would be painful. In fact other projects that have attempted to redo Cloud-init have generally failed due to poor adoption. The alternative to detecting clouds is to do a build per-cloud; this makes my spidey sense tingle as smaller clouds would end up being left out. IMO, that would run counter to the ethos of Debian since cloud images would be exclusive provenance of the bigger clouds. The other question that I have is how would FAI deal with snapshots/clones of prior booted machines. Most cloud's allow for some method of cloning an instance and then relaunching them. Without some agent that run each and every boot to determine if an instance is a new instance then a new instance may not be accessible or properly configured. I'll be the first to say that Cloud-init and related technologies are far from perfect, but right now Cloud-init is the best cross-distro technology. I support Cloud-init versions 0.7.5 through 17.01 on five distributions -- it is a never-ending headache, but it is far too useful to abandon. In my prior job I did quite a bit on the Cloud image builds for Ubuntu. My $0.02 single-source building doesn't work; it may serve the needs of the project but will fail to meet the needs of the Clouds. If the current build methods are insufficient, I would hope that we can come up with something that works for both Cloud and the Cloud user. Otherwise, what Debian will end up re-creating the Ubuntu Certified Public Cloud project (but worse). That said, I do like the idea of thinking outside the box. Part of the reason why I wanted to come to this sprint was providing Debian 9 on DigitalOcean was a bit of pain. I think it would be great if we can make Debian easier for clouds and their customers to consume and use. ~Ben On Sun, Oct 15, 2017 at 8:40 PM, Thomas Lange <[email protected] > wrote: > Here are my 10 cents, just some crazy ideas. > I had some time during my flight, so I wrote down some ideas. > You can also just ignore this and we start tomorrow from scratch. > > > Topics to work on > -------------------- > I think we can form several work groups > > 1) FAI config space for GCE, Azure, AWS > 2) how to create/boot/run the build VMs on casulana (involves DSA) > 3) create disk image inside VM > 4) test disk image in cloud environments > > > 1) have a look at the classes > We should have a class for every cloud and some general base classes > short description of each class what it does > > 2) We or DSA creates a golden disk image for the build VM, which we can > copy and start for every new build. > We could boot an empty VM from a FAI CD, which then installs our > build environment. > starting the VM via virsh, fai-kvm or ....? > see also additions to 2) below > > 3) log into VM, call fai-diskimage, save logs, copy disk image, shutdown VM > discard disk image of VM > > 4) Do we like to test the disk image also in a VM on casulana? > or just in the real cloud environment? > > > Do we use get a new user on casulana for the build process? > Should we set up a local package repository for newer packages? fai, > cloud-init, wagent,..... > > Will we use newer fai packages from fai-project.org or should Mrfai > provide official bpo packages? > > Workflow for changes of the FAI CS > Should every git push generate new images? > > ------------------------------ > 2) how to boot/create the build VM > > Which restrictions do DSA have? > private network for VMs > DSA will create tap devices in a bridge, tap devices belong to cduser > DHCP server in this private network > > Once the network is set up by DSA we are independent of DSA > > cduser can start VMs using fai-kvm > > - fai-kvm: start VM with a fixed MAC address to get a predefined IP > choose boot medium, nographics mode not yet available > SHOW fai-kvm -h > > create a disk image for our building VM using a FAI CD installation, > master.raw > then do build process > - copy master.raw to build1.raw > - start build VM using build1.raw > - rm build1.raw after the disk image was created inside VM > > > -- > regards Thomas > > -- Ben Howard (bh) Senior Engineer (720) 507 4209 [email protected] GPG: 3879 660B BDBF 23A4 DD0D 2620 4280 AEB1 E649 F26A
