CI: solve markdown style fails

Signed-off-by: Diana Popa <dpopa@amazon.com>
firecracker-microvm · Jan 6, 2021 · 77ef6425efdf33765443926d80fd62d011d7591c · 77ef642
1 parent dddff03
commit 77ef6425efdf33765443926d80fd62d011d7591c
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -7,7 +7,7 @@ assignees: ''
 
 ---
 
-## Describe the bug
+# Describe the bug
 
 `[Author TODO: A clear and concise description of what the bug is.]`
 
@@ -40,6 +40,7 @@ assignees: ''
 `[Author TODO: Do you have any idea of what the solution might be?]`
 
 ## Checks
+
 - [ ] Have you searched the Firecracker Issues database for similar problems?
 - [ ] Have you read the existing relevant Firecracker documentation?
 - [ ] Are you certain the bug being reported is a Firecracker issue?
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -7,17 +7,20 @@ assignees: ''
 
 ---
 
-## Why is this feature request important?  What are the use cases?  Please describe.
+# Feature Request
 
-`[Author TODO: A clear and concise description of what the problem is.]`
+`[Author TODO: Why is this feature request important? What are the use cases?
+Please describe.]`
 
 ## Describe the desired solution
 
-`[Author TODO: A clear and concise description of how you would like the feature to work.]`
+`[Author TODO: A clear and concise description of how you would like
+the feature to work.]`
 
 ## Describe possible alternatives
 
-`[Author TODO: A clear and concise description of any alternative solutions or features you have considered.]`
+`[Author TODO: A clear and concise description of any alternative solutions
+or features you have considered.]`
 
 `[Author TODO: How do you work around not having this feature?]`
 
@@ -26,6 +29,7 @@ assignees: ''
 `[Author TODO: Add additional context about this feature request here.]`
 
 ## Checks
+
 - [ ] Have you searched the Firecracker Issues database for similar requests?
 - [ ] Have you read all the existing relevant Firecracker documentation?
 - [ ] Have you read and understood Firecracker's core tenets?
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -1,4 +1,4 @@
-## Reason for This PR
+# Reason for This PR
 
 `[Author TODO: add issue # or explain reasoning.]`
 

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -3,6 +3,7 @@
 ## [Unreleased]
 
 ### Changed
+
 - Changed Docker images repository from DockerHub to Amazon ECR.
 
 ## [0.24.0]
@@ -23,7 +24,8 @@
 ### Changed
 
 - Change the information provided in `DescribeInstance` command to provide microVM
-  state information (Not started/Running/Paused) instead of whether it's started or not.
+  state information (Not started/Running/Paused) instead of whether it's
+  started or not.
 - Removed the jailer `--extra-args` parameter. It was a noop, having been
   replaced by the `--` separator for extra arguments.
 - Changed the output of the `--version` command line parameter to include a list

diff --git a/CHARTER.md b/CHARTER.md
@@ -9,7 +9,7 @@ execution of container and function workloads.
 
 These tenets guide Firecracker's development:
 
-1. **Built-In Security**: We provide compute security barriers that 
+1. **Built-In Security**: We provide compute security barriers that
    enable multi-tenant workloads, and cannot be mistakenly disabled by
    customers. Customer workloads are simultaneously considered sacred
    (shall not be touched) and malicious (shall be defended against).

diff --git a/CREDITS.md b/CREDITS.md
@@ -15,7 +15,6 @@ written in Rust with a focus on safety and security. Thanks go to:
 * [Jason D. Clinton](https://github.com/jclinton) <jclinton@chromium.org>
 * Sonny Rao <sonnyrao@chromium.org>
 
-
 Contributors to the Firecracker repository:
 
 * Aaron Hill <aa1ronham@gmail.com>

diff --git a/FAQ.md b/FAQ.md
@@ -133,7 +133,7 @@ Example of a kernel valid command
 line that enables the serial console (which goes in the `boot_args` field of
 the `/boot-source` Firecracker API resource):
 
-```
+```console
 console=ttyS0 reboot=k panic=1 pci=off nomodules
 ```
 
@@ -156,10 +156,12 @@ calls into kvm ptp instead of actual network NTP traffic.
 
 To be able to do this you need to have a guest kernel compiled with `KVM_PTP`
 support:
-```
+
+```console
 CONFIG_PTP_1588_CLOCK=y
 CONFIG_PTP_1588_CLOCK_KVM=y
 ```
+
 Our [recommended guest kernel config](resources/microvm-kernel-x86_64.config)
 already has these included.
 
@@ -169,8 +171,8 @@ Now `/dev/ptp0` should be available in the guest. Next you need to configure
 For example when using `chrony`:
 
 1. Add `refclock PHC /dev/ptp0 poll 3 dpoll -2 offset 0` to the chrony conf
-file (`/etc/chrony/chrony.conf`)
-2. Restart the `chrony` daemon.
+   file (`/etc/chrony/chrony.conf`)
+1. Restart the `chrony` daemon.
 
 You can see more info about the `refclock` parameters
 [here](https://chrony.tuxfamily.org/doc/3.4/chrony.conf.html#refclock).
@@ -192,7 +194,7 @@ For example, when you create two network interfaces by calling
 `/network-interfaces/1` and then `/network-interfaces/0`, it may result in this
 mapping:
 
-```
+```console
 /network-interfaces/1 -> eth0
 /network-interfaces/0 -> eth1
 ```
@@ -202,8 +204,9 @@ mapping:
 Firecracker does not implement ACPI and PM devices, therefore operations like
 gracefully rebooting or powering off the guest are supported in unconventional ways.
 
-Running the `poweroff` or `halt` commands inside a Linux guest will bring it down but
-Firecracker process remains unaware of the guest shutdown so it lives on.
+Running the `poweroff` or `halt` commands inside a Linux guest will bring it
+down but Firecracker process remains unaware of the guest shutdown so it lives
+on.
 
 Running the `reboot` command in a Linux guest will gracefully bring down the guest
 system and also bring a graceful end to the Firecracker process.
@@ -222,7 +225,7 @@ docs/rootfs-and-kernel-setup.md).
 
 If you see errors like ...
 
-```
+```console
 [<TIMESTAMP>] fc_vmm: page allocation failure: order:6, mode:0x140c0c0
 (GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null)
 [<TIMESTAMP>] fc_vmm cpuset=<GUID> mems_allowed=0
@@ -233,6 +236,7 @@ allocation of 2^`order` bytes (in this case, 6) and there aren't sufficient
 contiguous pages.
 
 Possible mitigations are:
+
 - Track the failing allocations in the `dmesg` output and rebuild the host
   kernel so as to use `vmalloc` instead of `kmalloc` for them.
 - Reduce memory pressure on the host.
@@ -246,17 +250,19 @@ the microVM. One example of such file can be found at `tests/framework/vm_config
 
 ### Firecracker fails to start and returns an Out of Memory error
 
-If the Firecracker process exits with `12` exit code (`Out of memory` error), the root
-cause is that there is not enough memory on the host to be used by the Firecracker microVM.
+If the Firecracker process exits with `12` exit code (`Out of memory` error),
+the root cause is that there is not enough memory on the host to be used by the
+Firecracker microVM.
 
 If the microVM was not configured in terms of memory size through an API request,
 the host needs to meet the minimum requirement in terms of free memory size,
 namely 128 MB of free memory which the microVM defaults to.
 
 ### Firecracker fails to start and returns "Resource busy" error
 
-If another hypervisor like VMware or VirtualBox is running on the host and locks `/dev/kvm`,
-Firecracker process will fail to start with "Resource busy" error.
+If another hypervisor like VMware or VirtualBox is running on the host and
+locks `/dev/kvm`, Firecracker process will fail to start with "Resource busy"
+error.
 
 This issue can be resolved by terminating the other hypervisor running on the host,
 and allowing Firecracker to start.
diff --git a/docs/RELEASE_POLICY.md b/docs/RELEASE_POLICY.md
@@ -8,12 +8,12 @@ customers effectively plan their Firecracker based operations.
 
 Firecracker uses [semantic versioning](http://semver.org/) for all releases.
 Semantic versions are comprised of three fields in the form:
-
-    vMAJOR.MINOR.PATCH
+`vMAJOR.MINOR.PATCH`.
 
 For example: v0.20.0, v0.22.0-beta5, and v99.123.77+foo.bar.baz.5.
 
 Firecracker publishes major, minor and patch releases:
+
 * Patch release - The `PATCH` field is incremented whenever critical bugs and/or
   security issues are found in a supported release. The fixes in a PATCH release
   do not change existing behavior or the user interface. Upgrade is recommended.
@@ -37,7 +37,7 @@ Firecracker publishes major, minor and patch releases:
 ## Release support
 
 The Firecracker maintainers will only provide support for Firecracker releases
-under https://github.com/firecracker-microvm/firecracker/releases.
+under our [repository's release page](https://github.com/firecracker-microvm/firecracker/releases).
 
 The Firecracker maintainers will provide patch releases for critical bugs and
 security issues when they are found, for:
@@ -47,35 +47,34 @@ security issues when they are found, for:
 * any Firecracker `vMAJOR.MINOR` release for at least 6 months from release date;
 * for each `vMAJOR`, the latest `MINOR` for 1 year since release date;
 
-#### Examples:
+### Examples
 
 1. Considering an example where the last Firecracker releases are:
-    * v2.10.0 released on 2022-05-01
-    * v2.11.0 released on 2022-07-10
-    * v2.12.0 released on 2022-09-11
+  * v2.10.0 released on 2022-05-01
+  * v2.11.0 released on 2022-07-10
+  * v2.12.0 released on 2022-09-11
 
-    In case of an event occurring in 2022-10-03, all three releases will be
-    patched since less than 6 months elapsed from their MINOR release time.
+  In case of an event occurring in 2022-10-03, all three releases will be
+  patched since less than 6 months elapsed from their MINOR release time.
 
 1. Considering an example where the last Firecracker releases are:
-    * v2.10.0 released on 2022-05-01
-    * v2.11.0 released on 2022-07-10
-    * v2.12.0 released on 2022-09-11
+  * v2.10.0 released on 2022-05-01
+  * v2.11.0 released on 2022-07-10
+  * v2.12.0 released on 2022-09-11
 
-    In case of of an event occurring in 2023-05-04, v2.11 and v2.12 will be
-    patched since those were the last 2 Firecracker major releases and less than
-    an year passed since their release time.
+  In case of of an event occurring in 2023-05-04, v2.11 and v2.12 will be
+  patched since those were the last 2 Firecracker major releases and less than
+  an year passed since their release time.
 
 1. Considering an example where the last Firecracker releases are:
-    * v2.14.0 released on 2022-05-01
-    * v3.0.0 released on 2022-07-10
-    * v3.1.0 released on 2022-09-11
-
-    In case of of an event occurring in 2023-01-13, v2.14 will be patched since
-    is the last minor of v2 and has less than one year since release while v3.0
-    and v3.1 will be patched since were the last two Firecracker releases and
-    less than 6 months have passed since release time.
-
+  * v2.14.0 released on 2022-05-01
+  * v3.0.0 released on 2022-07-10
+  * v3.1.0 released on 2022-09-11
+
+  In case of of an event occurring in 2023-01-13, v2.14 will be patched since
+  is the last minor of v2 and has less than one year since release while v3.0
+  and v3.1 will be patched since were the last two Firecracker releases and
+  less than 6 months have passed since release time.
 
 ## Developer preview features
 

diff --git a/docs/api_requests/actions.md b/docs/api_requests/actions.md
@@ -56,7 +56,9 @@ the guest OS. For Linux, that means the guest kernel needs
 a few tens of milliseconds probing the device. This can be disabled by using
 these kernel command line parameters:
 
-```i8042.noaux i8042.nomux i8042.nopnp i8042.dumbkbd```
+```console
+i8042.noaux i8042.nomux i8042.nopnp i8042.dumbkbd
+```
 
 **Note2** This action is only supported on `x86_64` architecture.
 

diff --git a/docs/api_requests/patch-block.md b/docs/api_requests/patch-block.md
@@ -1,22 +1,37 @@
-## Updating block devices after boot
+# Updating block devices after boot
 
-Firecracker offers support to update attached block devices after the microVM has been started. This is provided via PATCH /drives API which notifies Firecracker that the underlying block file has been changed on the host. It should be called when the path to the block device is changed or if the file size has been modified. It is important to note that external changes to the block device file do not automatically trigger a notification in Firecracker so the explicit PATCH API call is mandatory.
+Firecracker offers support to update attached block devices after the microVM
+has been started. This is provided via PATCH /drives API which notifies
+Firecracker that the underlying block file has been changed on the host. It
+should be called when the path to the block device is changed or if the file
+size has been modified. It is important to note that external changes to the
+block device file do not automatically trigger a notification in Firecracker
+so the explicit PATCH API call is mandatory.
 
 ## How it works
 
-The implementation of the PATCH /drives API does not modify the host backing file. It only updates the emulation layer block device properties, path and length and then triggers a virtio device reconfiguration that is handled by the guest driver which will update the size of the raw block device.
-With that being said, a sequence which performs resizing/altering of the block underlying host file followed by a PATCH /drives API call is not an atomic operation as the guest can also modify the block file via emulation during the sequence, if the raw block device is mounted or accessible.
+The implementation of the PATCH /drives API does not modify the host backing
+file. It only updates the emulation layer block device properties, path and
+length and then triggers a virtio device reconfiguration that is handled by the
+guest driver which will update the size of the raw block device.
+With that being said, a sequence which performs resizing/altering of the block
+underlying host file followed by a PATCH /drives API call is not an atomic
+operation as the guest can also modify the block file via emulation during
+the sequence, if the raw block device is mounted or accessible.
 
 ## Supported use case
 
-This feature was designed to work with a cooperative guest in order to effectively simulate hot plug/unplug functionality for block devices.
+This feature was designed to work with a cooperative guest in order to
+effectively simulate hot plug/unplug functionality for block devices.
 
 The following guarantees need to be provided:
-* guest did not mount the device
-* guest does not read or write from the raw block device /dev/vdX during the update sequence
 
+* guest did not mount the device
+* guest does not read or write from the raw block device `/dev/vdX` during the
+  update sequence
 
-Example sequence that configures a microVM with a placeholder drive and then updates it with the real one:
+Example sequence that configures a microVM with a placeholder drive and then
+updates it with the real one:
 
 ```bash
 # Create and set up a block device.
@@ -26,11 +41,11 @@ curl --unix-socket ${socket} -i \
      -X PUT "http://localhost/drives/scratch" \
      -H "accept: application/json" \
      -H "Content-Type: application/json" \
-     -d "{            
+     -d "{
              \"drive_id\": \"scratch\",
-             \"path_on_host\": \"${ro_drive_path}\",            
-             \"is_root_device\": false,            
-             \"is_read_only\": true         
+             \"path_on_host\": \"${ro_drive_path}\",
+             \"is_root_device\": false,
+             \"is_read_only\": true
          }"
 # Finish configuring and start the microVM. Wait for the guest to boot.
 
@@ -48,22 +63,33 @@ curl --unix-socket ${socket} -i \
      -H "accept: application/json" \
      -H "Content-Type: application/json" \
      -d "{
-             \"drive_id\": \"scratch\",            
-             \"path_on_host\": \"${updated_ro_drive_path}\"         
+             \"drive_id\": \"scratch\",
+             \"path_on_host\": \"${updated_ro_drive_path}\"
          }"
-         
+
 # It's now safe to mount the block device in the guest and use it
 # with the updated backing file.
 ```
 
 ## Data integrity and other issues
 
-We do not recommend using this feature outside of its supported use case scope. If the required guarantees are not provided, data integrity and potential other issues may arise depending on the actual use case. There are two major aspects that need be considered here:
+We do not recommend using this feature outside of its supported use case scope.
+If the required guarantees are not provided, data integrity and potential other
+issues may arise depending on the actual use case. There are two major aspects
+that need be considered here:
 
 ### Atomicity of the update sequence
 
-If the guest has the opportunity to perform I/O against the block device during the update sequence it can either read data while it is changed or can overwrite data already written by a host process. For example a truncate operation can be undone if the guest issues a write for the last sector of the raw block device, or the guest application can become inconsistent or/and can create inconsistency in the block device itself.
+If the guest has the opportunity to perform I/O against the block device during
+the update sequence it can either read data while it is changed or can
+overwrite data already written by a host process. For example a truncate
+operation can be undone if the guest issues a write for the last sector of the
+raw block device, or the guest application can become inconsistent or/and can
+create inconsistency in the block device itself.
 
 ### In flight I/O requests
 
-If the atomicity of the operation is guaranteed by using methods to make the microVM quiescence during the update sequence (for example pausing the microVM) the guest itself or block device can still become incosistent from in flight I/O requests in the guest that will be executed after it is resumed.
+If the atomicity of the operation is guaranteed by using methods to make the
+microVM quiescence during the update sequence (for example pausing the microVM)
+the guest itself or block device can still become incosistent from in flight
+I/O requests in the guest that will be executed after it is resumed.