We had we had Cloud Team BoF during DebConf 18 in Taiwan, on 2018-07-30. We started with short summary of what happened since last year: sprint in October 2017 in Seattle, hosted by Microsoft Azure team. We still work on moving all our build processes to use FAI - but for GCE, AWS, and Azure images it’s mostly done for current stable.
We have new kernel images, with Kconfig customised for cloud needs, prepared in cooperation between Credativ and Microsoft. On Microsoft Azure it halves boot time. We should probably install it by default on our images - but first we need to test it. There is new machine, casulana.debian.org, which will be used by team to build images and test them (i.e. start VM with just-built image, perform some tests, etc.) All our repositories are now on Salsa: https://salsa.debian.org/cloud-team We might want to use Salsa CI to automatically tests and publish build images, but first we need to have process to automatically build them; for now there is still to many manual steps involved. We are also not so sure whether we can use Salsa CI directly - our process will be more complex, with many interleaved steps: build image, test file, run VM on casulana and run some tests, push image to cloud vendor, run some tests there,… During last sprint we worked on solution to test our images. We have code and set of tests, but they run tests only on cloud machines (currently AWS and GCE, no Azure yet) and require manual configuration and running. There are also various scripts to run VMs (e.g. on casulana) but there is many of them, each serving slightly different purpose. We’ll need to review them, and possibly integrate them into our testing/building framework. We need to have official Debian account to serve as publisher of images in cloud vendors’ marketplaces; it’ll most probably be managed by SPI. We also need to have official Debian account to manage users’ access to clouds, to have federated identity - for example to disable access of retired DDs, etc. It’ll also be needed to manage automated credentials, to be used by testing framework, mentioned in above paragraph. There is more and more OpenStack-based cloud providers. We were shortly dis- cussing how to provide images to them. For now rough consensus is that we’ll have hooks which will be called when there is new image build - and they can registers listeners to those hooks. But is’s lower priority for now - first we need to have automated build/testing/publishing pipeline. We also haven’t thought about managing those hooks/listeners, especially credentials needed by them. Also - some providers, like Alibaba (among others) might need to have some special needs, or to require special software installed. Which led to another topic - installing agents/daemons on images. Such agents run on instance and help maintaining such instance - for example inject SSH keys, provide better performance monitoring, etc. Their usage is not always required (e.g. one cur run and use instance on AWS) but greatly helps with advanced functio- nality. In other words, lacking them puts Debian to be second-class citizen. Agents for Azure are in good shape (they are in archive). Agents for GCE are in Google repository, and there are problems (mostly DFSG and package quality-related) which prevent from them being accepted into main. As for AWS, no work has been done to package them. There is other problems with such agents - they need to be updated quite frequently. This will require cooperation between vendors, Release Team, and cloud team. But first we need to have more automated workflow, especially testing, to show Release Team that they can allow for updating new versions (in other words - that we know what we’re doing). If we want to have new software in Buster, we’ll need to have it in archive before freeze - so still this year. We already publish many images, with many versions. Also each cloud provider usually has separate images for separate regions. Currently one needs to consult our wiki (e.g. https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch) or know Debian account ID to find them. It would be nice to have image finder, similar to one available for Ubuntu. Canonical hasn’t open-sourced its code however, so we’d need to write our own. There was intensive discussion related to automated/unattended upgrades of our images: whether we should do it at all (there may be run in environment w/o internet access), when (usage needs, avoiding killing mirror when thousands of machines try to perform upgrade at once, etc.). Some vendors upgrade during restart, but it lengthens boot time, which matters when VM is run for short time (common use case for clouds). No consensus was found - but we should check what Ubuntu does. We haven’t discussed cloud-init situation - need to update its version, etc. We need to better document our process and solutions; but potentially we have one volunteer :-) We plan to have another Cloud Sprint in Autumn, but dates (and place for that matter) are not yet set. If somebody notices some omissions - please add new information. I’ll watch recording of our session and probably add more details - but definitely not in the next 2 weeks. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C