Clarify the mission on updates, state, and scope

Updates are the quintessential operation. Add further clarification
on expectations related to state, and factory reset.

In particular, it should be easier for people to understand what is
and isn't candidates for including in a bootable container definition,
images, artifacts and implementing in the underlying components.

Just like containers have scope so do bootable containers, and certain
deployment choices don't belong in this technology.

Signed-off-by: Stef Walter <[email protected]>

index.md

@@ -24,8 +24,18 @@ The system either uses the contents of the old system, or the new image; Never s
 Updates can be delayed or scheduled.
 This default behavior can be adapted or controlled by a larger management system.
 
-1. It should always be possible to factory reset back to either the known built behavior of the system or roll back to previous behavior if an updated image does not function correctly.
+1. If an update does not function correctly it is possible to roll back to the container image previously functioning before the update.
+
+1. State (including per-machine configuration) is preserved across updates.
+State is written to specific writable directories on the system, by default these are /etc and /var.
+
+1. It should always be possible to factory reset back to the known built behavior of the system, by discarding all state (and per machine configuration) not present in the container image.
 
 1. It should be supported to create a cryptographic trust chain that runs from the hardware, through the boot loader, through the operating system all the way to the applications ensures that only the expected code is run, and the contents of the operating system and applications have not been changed unexpectedly.
 If something has been changed, or changes at runtime unexpectedly, the system can alert or stop.
 The builder of the images can sign the images with keys that are under their own control, or of course build images and deploy systems without a trust chain.  But, it also continues to be supported by system builders to create "unlocked" systems where the end user can make local unsigned changes.
+
+1. Updates are the quintessential operation for deploying bootable containers.
+It is tempting to include any and all system deployment information in a bootable container artifacts, definitions or images.
+Only configuration and deployment choices that can be successfully deployed via a new container image update to an existing system, or via a factory reset, are those that belong in the bootable container definitions or images.
+A canonical example is disk partition layout: this attribute of a deployment cannot be changed via an updated container image, and thus is the responsibility of an installer or infrastructure providing the system, rather than bootable containers.