DebConf18 Cloud Team BoF summary
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
Reply to: