(docs): Clean Up

README.md

@@ -45,13 +45,11 @@ curl -L \
 sudo install -m755 /tmp/ebs-bootstrap /usr/local/sbin/ebs-bootstrap
 ```
 
-## Modes
+## Documentation
 
-// TODO
-
-## Configuration
-
-// TODO
+<a href="https:/reecetech/ebs-bootstrap/wiki">
+ <img src="https://img.shields.io/badge/github-%23121011.svg?style=for-the-badge&logo=github&logoColor=white">
+</a>
 
 ## Use Cases
 
@@ -113,7 +111,7 @@ WantedBy=multi-user.target
 
 By default, `ebs-bootstrap` consumes a configuration file located at `/etc/ebs-boostrap/config.yml`. `cloud-init` can be configured to write a config to this location, using the `write_files` module. Ensure that `ebs-bootstrap` is installed on your Instance via the process of baking it into your Golden AMI or downloading it early in the boot process, using the `runcmd` module.
 
-The advent of Instance Store provided Nitro-enabled EC2 instances the ability to harness the power of high speed NVMe. However, these Instance Store devices were ephemeral and had to be formatted and mounted on each startup cycle. For a stateful workload like a database, you might want a fast and ephemeral space for temporary tables, alongside a stateful EBS volume declared in a different CloudFormation Stack, separate from your compute.
+The advent of Instance Store provided Nitro-enabled EC2 instances the ability to harness the power of high speed NVMe. However, these Instance Store devices were ephemeral and had to be formatted and mounted on each startup cycle. For a stateful workload like a database, you might want a fast and ephemeral space for temporary tables, alongside a stateful EBS volume declared in a different CloudFormation Stack.
 
 From the perspective of a **sceptical** Platforms Engineer, you do not mind a tool like `ebs-bootstrap` automating the task of formatting and mounting an ephemeral device. However, you personally draw the line on automation executing modifications to a stateful device, **without** the prior consent of a human. `ebs-bootstrap` empowers this Platform Engineer by allowing them to specify the execution mode, on a **device-by-device** basis: Instance Store (`force`) and EBS Volume (`healthcheck`)
 
@@ -124,10 +122,10 @@ Resources:
  ...
  InstanceType: m5ad.large # Nitro Instance Type
  Volumes:
- - Device: /dev/sdb # EBS Volume (Stateful)
- VolumeId: !ImportValue EbsVolumeId
+ - Device: /dev/sdb # EBS Volume
+ VolumeId: !ImportValue StatefulVolumeId
  BlockDeviceMappings:
- - DeviceName: /dev/sdh # Instance Store (Ephemeral)
+ - DeviceName: /dev/sdh # Instance Store
  VirtualName: ephemeral0
  UserData:
  Fn::Base64: !Sub
@@ -155,22 +153,12 @@ Resources:
  label: ephemeral
  mode: force
  path: /etc/ebs-bootstrap/config.yml
- runcmd:
+ bootcmd:
  - curl -L -o /tmp/ebs-bootstrap "${EbsBootstrapUrlPrefix}-$(uname -m)"
  - install -m755 /tmp/ebs-bootstrap /usr/local/sbin/ebs-bootstrap
- bootcmd:
+ runcmd:
  - /usr/local/sbin/ebs-bootstrap
  - FileSystem: ext4
  MountOptions: defaults,nofail,x-systemd.device-timeout=5
- EbsBootstrapUrlPrefix: >
- https:/reecetech/ebs-bootstrap/releases/download/latest/ebs-bootstrap-linux
+ EbsBootstrapUrlPrefix: https:/reecetech/ebs-bootstrap/releases/latest/download/ebs-bootstrap-linux
 ```
-
-## Architecture
-
-**Portability** was one of the key reasons why `ebs-bootstrap` was programmed in the Go programming language. The ease of distributing a single statically-compiled binary out-weighted the reduced development and testing complexity a language like Python would have brought. By producing a statically-compiled binary, we ensure that this tool is supported across common AWS-supported Linux distributions: Amazon Linux, RHEL/CentOS Derivatives and Ubuntu.
-
-For some insight about the layer architecture implemented by `ebs-bootstrap`, refer to the annotated UML diagram below.
-
-
-![UML Diagram of ebs-bootstrap Architecture](assets/uml.drawio.svg)

internal/action/format.go

@@ -39,9 +39,9 @@ func (a *FormatDeviceAction) Prompt() string {
 }
 
 func (a *FormatDeviceAction) Refuse() string {
- return fmt.Sprintf("Refused to format to %s", a.fileSystemService.GetFileSystem())
+ return fmt.Sprintf("Refused to format %s to %s", a.device, a.fileSystemService.GetFileSystem())
 }
 
 func (a *FormatDeviceAction) Success() string {
- return fmt.Sprintf("Successfully formatted to %s", a.fileSystemService.GetFileSystem().String())
+ return fmt.Sprintf("Successfully formatted %s to %s", a.device, a.fileSystemService.GetFileSystem().String())
 }

internal/action/format_test.go

@@ -36,12 +36,12 @@ func TestFormatDeviceActionMessages(t *testing.T) {
  {
  Name: "Refuse",
  Message: fda.Refuse(),
- ExpectedOutput: "Refused to format to ext4",
+ ExpectedOutput: "Refused to format /dev/xvdf to ext4",
  },
  {
  Name: "Success",
  Message: fda.Success(),
- ExpectedOutput: "Successfully formatted to ext4",
+ ExpectedOutput: "Successfully formatted /dev/xvdf to ext4",
  },
  }
  for _, subtest := range subtests {

internal/action/label.go

@@ -41,9 +41,9 @@ func (a *LabelDeviceAction) Prompt() string {
 }
 
 func (a *LabelDeviceAction) Refuse() string {
- return fmt.Sprintf("Refused to label to '%s'", a.label)
+ return fmt.Sprintf("Refused to label %s to '%s'", a.device, a.label)
 }
 
 func (a *LabelDeviceAction) Success() string {
- return fmt.Sprintf("Successfully labelled to '%s'", a.label)
+ return fmt.Sprintf("Successfully labelled %s to '%s'", a.device, a.label)
 }

internal/action/label_test.go

@@ -36,12 +36,12 @@ func TestLabelDeviceActionMessages(t *testing.T) {
  {
  Name: "Refuse",
  Message: lda.Refuse(),
- ExpectedOutput: "Refused to label to 'example'",
+ ExpectedOutput: "Refused to label /dev/xvdf to 'example'",
  },
  {
  Name: "Success",
  Message: lda.Success(),
- ExpectedOutput: "Successfully labelled to 'example'",
+ ExpectedOutput: "Successfully labelled /dev/xvdf to 'example'",
  },
  }
  for _, subtest := range subtests {