Talk about butane as declarative format

os/coreos-layering.md

@@ -30,7 +30,7 @@ For users who are happy with Fedora CoreOS today, not much will change.
 
 For those who e.g. want to install custom agents or nontrivial amounts of code (such as kubelet), this "CoreOS layering" will be a powerful new mechanism to ship the code they need.
 
-# Example
+# Example via Dockerfile
 
 [fcos-derivation-example](https://github.com/cgwalters/fcos-derivation-example) contains an example `Dockerfile` that builds a Go binary and injects it along with a corresponding systemd unit as a layer, building on top of Fedora CoreOS.
 
@@ -57,10 +57,33 @@ RUN rpm -Uvh https://kojipkgs.fedoraproject.org//packages/strace/5.14/1.fc34/x86
 
 # Derivation versus Ignition/butane
 
-This proposal does not replace Ignition.  Ignition will still play two key roles:
+This proposal does not replace Ignition.  Ignition will still play at least two key roles:
 
 - Setting up partitions and storage, e.g. LUKS is something configured via Ignition provided on boot.
 - Machine/node specific configuration, in particular bootstrap configuration: e.g. static IP addresses that are necessary to fetch container images at all.
+
+# Butane as a declarative input format for layering
+
+We must support `Dockerfile`, because it's the lowest common denominator for the container ecosystem, and is accepted as input for many tools.
+
+However, one does not have to use `Dockerfile` to make containers.  Specifically, an option is for us to offer a `quay.io/fedora/coreos-butane-builder` tool that accepted butane syntax and created a layer.
+
+This could run as a "builder" container, something like this:
+
+```
+FROM quay.io/fedora/coreos-butane-builder as builder
+COPY . .
+RUN butane -o /build/ignition.json
+
+FROM quay.io/fedora/coreos:stable
+COPY --from=builder /build/ignition.json /tmp/
+RUN ignition --write-filesystem /tmp/ignition.json && rm -f /tmp/ignition.json
+```
+
+Another option is to support being run nested inside an existing container tool, similar to
+[kaniko](https://github.com/GoogleContainerTools/kaniko).  Then no
+`Dockerfile` would be needed.
+
 # Use of CoreOS disk/boot images
 
 And more explicitly, it's expected that many if not most users would continue to use the official Fedora CoreOS "boot images" (e.g. ISO, AMI, qcow2, etc.).  This proposal does *not* currently call for exposing a way for a user to create the boot image shell around their custom container, although that is an obvious potential next step.