Merge pull request flatcar#286 from flatcar/tormath1/mounting-storage

mounting-storage: migrate to butane

content/docs/latest/setup/storage/mounting-storage.md

@@ -7,25 +7,25 @@ aliases:
     - ../../clusters/scaling/mounting-storage
 ---
 
-Container Linux Configs can be used to format and attach additional filesystems to Flatcar Container Linux nodes, whether such storage is provided by an underlying cloud platform, physical disk, SAN, or NAS system. This is done by specifying how partitions should be mounted in the config, and then using a _systemd mount unit_ to mount the partition. By [systemd convention][systemd-mount-man], mount unit names derive from the target mount point, with interior slashes replaced by dashes, and the `.mount` extension appended. A unit mounting onto `/var/www` is thus named `var-www.mount`.
+Butane Configs can be used to format and attach additional filesystems to Flatcar Container Linux nodes, whether such storage is provided by an underlying cloud platform, physical disk, SAN, or NAS system. This is done by specifying how partitions should be mounted in the config, and then using a _systemd mount unit_ to mount the partition. By [systemd convention][systemd-mount-man], mount unit names derive from the target mount point, with interior slashes replaced by dashes, and the `.mount` extension appended. A unit mounting onto `/var/www` is thus named `var-www.mount`.
 
 Mount units name the source filesystem and target mount point, and optionally the filesystem type. *Systemd* mounts filesystems defined in such units at boot time. The following example formats an [EC2 ephemeral disk][ec2-disk] and then mounts it at the node's `/media/ephemeral` directory. The mount unit is therefore named `media-ephemeral.mount`.
 
 Note that you should not use the direct path `/dev/sdX`for the `What=` path but **use a distinct stable identifier** such as `/dev/disk/by-label/X` or `/dev/disk/by-partlabel/X` because, e.g., `/dev/sda` can become `/dev/sdb` after reboot as the Linux kernel assigns the devices in the order they appear which can be unstable. The best idea is to match the disk based on the content you expect, such as a filesystem or partition label that you set up through formatting the disk on first boot via Ignition's `mount:` directive. This way you can use `/dev/sdX` as the `mount: device:` path which is only used on the first boot and don't have to care whether it will get different names after reboot because your mount unit uses `/dev/disk/by-label/` to find the correct disk. If that is not possible you can try your luck with `/dev/disk/by-path/X` entries that depend on the way the disk are attached to the machine but not on the discovery order of the Linux kernel.
 
 ```yaml
+variant: flatcar
+version: 1.0.0
 storage:
   filesystems:
-    - name: ephemeral1
-      mount:
-        device: /dev/xvdb
-        format: ext4
-        wipe_filesystem: true
-        label: ephemeral1
+    - device: /dev/xvdb
+      format: ext4
+      wipe_filesystem: true
+      label: ephemeral1
 systemd:
   units:
     - name: media-ephemeral.mount
-      enable: true
+      enabled: true
       contents: |
         [Unit]
         Before=local-fs.target
@@ -44,18 +44,18 @@ Docker containers can be very large and debugging a build process makes it easy
 We're going to format a device as ext4 and then mount it to `/var/lib/docker`, where Docker stores images. Be sure to hardcode the correct device or look for a device by label:
 
 ```yaml
+variant: flatcar
+version: 1.0.0
 storage:
   filesystems:
-    - name: ephemeral1
-      mount:
-        device: /dev/xvdb
-        format: ext4
-        wipe_filesystem: true
-        label: ephemeral1
+    - device: /dev/xvdb
+      format: ext4
+      wipe_filesystem: true
+      label: ephemeral1
 systemd:
   units:
     - name: var-lib-docker.mount
-      enable: true
+      enabled: true
       contents: |
         [Unit]
         Description=Mount ephemeral to /var/lib/docker
@@ -82,6 +82,8 @@ Flatcar Container Linux uses ext4 + overlayfs to provide a layered filesystem fo
 In this example, we are going to mount a new 25GB btrfs volume file to `/var/lib/docker`. One can verify that Docker is using the btrfs storage driver once the Docker service has started by executing `sudo docker info`. We recommend allocating **no more than 85%** of the available disk space for a btrfs filesystem as journald will also require space on the host filesystem.
 
 ```yaml
+variant: flatcar
+version: 1.0.0
 systemd:
   units:
     - name: format-var-lib-docker.service
@@ -95,7 +97,7 @@ systemd:
         ExecStart=/usr/bin/truncate --size=25G /var/lib/docker.btrfs
         ExecStart=/usr/sbin/mkfs.btrfs /var/lib/docker.btrfs
     - name: var-lib-docker.mount
-      enable: true
+      enabled: true
       contents: |
         [Unit]
         Before=docker.service
@@ -114,13 +116,15 @@ Note the declaration of `ConditionPathExists=!/var/lib/docker.btrfs`. Without th
 
 ## Mounting NFS exports
 
-This Container Linux Config excerpt mounts an NFS export onto the Flatcar Container Linux node's `/var/www`.
+This Butane Config excerpt mounts an NFS export onto the Flatcar Container Linux node's `/var/www`.
 
 ```yaml
+variant: flatcar
+version: 1.0.0
 systemd:
   units:
     - name: var-www.mount
-      enable: true
+      enabled: true
       contents: |
         [Unit]
         Before=remote-fs.target