There are a lot of options in persistConfig that aren't mentioned in the README. We should add a section to the README that documents each option you can declare in a persistConfig.

postcss before v8.2.10 (used by the React UI) is affected by CVE-2021-23368 (see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23368)

Output from npm list postcss:

+-- react-scripts@3.4.4
| +-- css-loader@3.4.2
| | +-- icss-utils@4.1.1
| | | `-- postcss@7.0.35  deduped
| | +-- postcss@7.0.35
| | +-- postcss-modules-extract-imports@2.0.0
| | | `-- postcss@7.0.35  dedupe

Before opening, please confirm:

• I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
• I have searched for duplicate or closed issues.
• I have read the guide for [submitting bug reports](https://github.com/aws-amplify/amplify-cli/blob/master/CONTR

Local PV (device) provisioner leaves a stale BDC in the following case:

• On PVC request, creates a BDC
• If the system doesn't have a matching BD, then PVC request keeps retrying, and so does the NDM operator that keeps retrying
• Now if the user deletes the PVC, then Local PV (device) provisioner doesn't get the trigger to process delete, as there was no PVC.

This causes the stale BDC

Context & Repro

Here's a minimal repro:

const db = new Dexie("MyDatabase");
db.version(1).stores({
    keys: "++id",
});

// Create a CryptoKey
const someCryptoKey = (
  await window.crypto.subtle.generateKey(
    {
      name: "RSA-OAEP",
      modulusLength: 4096,
      publicExponent: new Uint8Array([1, 0, 1]),
      hash: "SHA-256",
    },
    true,
    ["encrypt

13.2.5.55 DOCTYPE name state

EOF
Emit that DOCTYPE token

Change to "Emit the current DOCTYPE token" to match the style of the rest of the doc.

Here is an issues with detailed description: NekR/offline-plugin#77

We want to have consistent and structured logs to improve the ability to filter and analyse longhorn-manager logs.
Currently the controller uses the global logrus package logger, the task here would be to switch the log calls to the instance logger that was implemented in longhorn/longhorn-manager#661

While doing this also improve the log messages, where possible.
For an example of a successf