Stuff we're doing

  * Debian images in many clouds with lots of variation
  * Major cloud platforms have custom Debian images
  * Lots of variation, no “official” images

Stuff we should be doing

* official images produced by Debian
  * for better support
  * because users cannot trust the 3rd party additions
  * to protect the Debian “name”
  * Because they are a trusted starting point
    * for users who do not care to build their own custom image (yet?), and
    * for users to base a custom image on.

* Not prevent custom images

Official image requirements

* Produced by Debian people on Debian machines
  Mehdi: Is this always possible? Yes, including for Azure.
  Amazon? bootstrap one from another authorized one.

* Content
  * Everything needs to be from main
  * Categorise cloud images as pure blends?
  * virtualbox extensions? open question.
  * loading images remotely, check the image after installation?
    * depends on the platform
  * how to be sure of an official image?
  * include backports & security updates?
  * configuration? - cloud-init, yes.
  * Does any platform require contrib or non-free bits for cloud-init?
    * rackspace - specific agent which is not free or even visible.
  * faster development pace
  * one image only-main, one image main+selected-backports
    * Non-stable is still a pure blend
    * one per provider becomes problematic.
      * minimal stable only
      * stable+selected-backports
      * richer image with undefined additions
    * cloud-init needs to be configurable per provider
      * specific datasources slow down all provisions.
      * this is beyond the installer, so preseeding is not available.
    * cloud-init needs to be kept up to date - lots of bugs in old versions
      and things change rapidly
  * regenerate the images when security updates are available.
    * image to do a full upgrade on first-boot?
    * simultaneous upgrades from lots of images would raise other problems.
  * images which are currently running? unattended-upgrades is not the complete
    answer
    * Tension between providers and users
    * broader discussion outside of just cloud requirements.

* Documentation
  * reproducible and verifiable.
  * publish the manifest
  * know which tool and version was used with command line & config.
  * single git tree of modifications?

* QA
  * Need to devise a full test plan.

The plethora of tools does not serve the users well.
Riku's session at Debconf15 got into double digits with a count of tools.
Bless one particular tool - could get into a religious battle.
Come up with a minimal policy of what an image needs to look like
 * measure existing images against that policy to call these "official".
 * ensure the tool can add the preferred packages for custom images.
 * create a trusted place from where to start.

* Package list
  * cloud-init && ssh
  * screen vs tmux and other alternative packages.
  * minimal official images doing minimal installation.
    * one variant has lots of extras
    * problem with pinentry.
  * tiny images preferred - tools add the extras. Every extra 1% multiplies
    up with each new install. Pay per MB.
  * extended images can be created by individuals/groups.
  * look at the security footprint - complexity becomes problematic.
    * cloning and stacking images is a common task.
  * DSA runs cloud images too.

Plans

* No discussions on timeline or how to test have happened yet.
* Need to define the official image policy soon, due to the Stretch freeze.
* Please discuss.
* Take up Google on offer to host cloud-images sprint.


Sprint

* Google offering to host in Seattle.
* discuss on the cloud list
* everyone with an interest needs to be there.