Corrected punctuautions and errors on Introduction and architecture pages

Gbahdeyboh · Gbahdeyboh · commit f019f5fe106e · 2021-07-04T14:56:25.000+01:00
Signed-off-by: Gbadebo Bello &lt;gbahdeybohbello@gmail.com&gt;
diff --git a/website/docs/architecture.md b/website/docs/architecture.md
@@ -13,40 +13,33 @@ The above picture gives you a high-level architecture of the Litmus. At highleve
 1. Portal
 2. Agents 
 
-**Portal**  is a set of Litmus components which act as Cross Cloud Chaos Control plane (WebUI) which is be used to orchestrate and observe the chaos workflows on Agents.
+**Portal**  is a set of Litmus components which act as Cross Cloud Chaos Control plane (WebUI) which is used to orchestrate and observe the chaos workflows on Agents.
 
 **Agent** is the set of Litmus components which induces Chaos using the chaos workflows on the K8S cluster component.
 
-Typical user scenario, The user would install litmus. This would in-turn install Portal and Agent on the self cluster. Using the portal user can create/schedule new chaos workflows on the Agents and observe the results from here. User can also connect more clusters to the portal, and use the Portal as single window pane for cross cloud chaos management.
+A typical user scenario would be when a user would installs litmus, this would in-turn install Portal and Agent on the self cluster. Using the portal user can create/schedule new chaos workflows on the Agents and observe the results from here. Users can also connect more clusters to the portal, and use the Portal as single window pane for cross cloud chaos management.
 
 
-
-**Portal Components**
+#### Portal Components
 
 Portal has the following components
 
-- Litmus WebUI
-
-  Litmus UI provides web user interface, where user can construct and observe the chaos workflow at ease. Also this act as cross cloud chaos control plane that is
-
-- Litmus Server
-
-  Litmus Server act as middle ware which is use to handle API request from the user interface, store the config and results details into the DB. This also act as interface to communicate between the requests and scheduling the workflow to Agent.
+- **Litmus WebUI** <br />
+  Litmus UI provides web user interface, where a user can construct and observe the chaos workflow at ease. Also this act as a cross cloud chaos control plane.
 
-- Litmus DB 
+- **Litmus Server**<br />
+  Litmus Server act as middleware which is use to handle API request from the user interface, store the config and result details into the DB. This also act as an interface to communicate between the requests and scheduling the workflow to the Agent.
 
-  Litmus DB act as config store for chaos workflows and its results.
-
-**Agent components**
+- **Litmus DB**<br />
+  Litmus DB act as a config store for chaos workflows and its results.
 
+#### Agent components
 Agents has the following Litmus components
 
-- Chaos Operator 
-
-  Chaos-Operator watches for the ChaosEngine CR and executes the Chaos-Experiments mentioned in the CR. Chaos-Operator is namespace scoped. By default, it runs in `litmus` namespace. Once the experiment is completed, chaos-operator invokes chaos-exporter to export chaos metrics to a Prometheus database.
-
--  CRDs
+- **Chaos Operator**<br />
+  Chaos-Operator watches for the ChaosEngine CR and executes the Chaos-Experiments mentioned in the CR. Chaos-Operator is namespace scoped. By default, it runs on the `litmus` namespace. Once the experiment is completed, chaos-operator invokes chaos-exporter to export chaos metrics to a Prometheus database.
 
+-  **CRDs**<br />
    During installation, the following three CRDs are installed on the Kubernetes cluster.
 
   ```
@@ -55,27 +48,21 @@ Agents has the following Litmus components
   chaosresults.litmuschaos.io
   ```
 
-- Chaos Experiment
+- **Chaos Experiment**<br />
+  Chaos Experiment is a CR and are available as YAML files on [Chaos Hub](https://hub.litmuschaos.io/). For more details visit [Chaos Hub documentation](https://litmusdocs-beta.netlify.app/docs/chaoshub).
 
-  Chaos Experiment is a CR and are available as YAML files on [Chaos Hub](https://hub.litmuschaos.io/). For more details visit Chaos Hub [documentation](https://litmusdocs-beta.netlify.app/docs/chaoshub).
+- **Chaos Engine**<br />
+  ChaosEngine CR links application to experiments. User has to create ChaosEngine YAML by specifying the application label, it's experiments and create the CR. The CR is watched by Chaos-Operator and chaos-experiments are executed on a given application.
 
-- Chaos Engine
-
-  ChaosEngine CR links application to experiments. User has to create ChaosEngine YAML by specifying the application label and experiments and create the CR. The CR is watched by Chaos-Operator and chaos-experiments are executed on a given application.
-
-- Chaos Results
-
-  ChaosResult resource holds the results of a ChaosExperiment with a namespace scope. It is created or updated at runtime by the experiment itself. It holds important information like the ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference.
-
-- Chaos Probes
+- **Chaos Results**<br />
+  ChaosResult resource holds the results of a ChaosExperiment within a namespace scope. It is created or updated at runtime by the experiment itself. It holds important information like the ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference.
 
+- **Chaos Probes**<br />
   Litmus probes are pluggable checks that can be defined within the ChaosEngine for any chaos experiment. The experiment pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the experiment (along with the standard “in-built” checks).
 
-- Chaos Exporter
-
+- **Chaos Exporter**<br />
   Optionally metrics can be exported to a Prometheus database. Chaos-Exporter implements the Prometheus metrics endpoint.
 
-- Subscriber
-
+- **Subscriber**<br />
   Subscriber is the component used in Agent side which interact with Litmus Server component to get the details of Chaos workflow and send the results back.
 
diff --git a/website/docs/introduction.md b/website/docs/introduction.md
@@ -14,11 +14,11 @@ Service downtimes are always expensive and they are very difficult to predict an
 
 LitmusChaos is a complete framework to implement chaos engineering within a cloud-native ecosystem. It helps both Developers and SREs automate the chaos experiments at different stages within the DevOps pipeline like development, during CI/CD, & in production. 
 
-- What is a Chaos Experiment?
+#### What is a Chaos Experiment?
 
 Chaos Experiments are fundamental units within the LitmusChaos architecture. Users can choose between readily available chaos experiments or create new ones to construct a required chaos workflow. 
 
-- What is a Chaos Workflow?
+#### What is a Chaos Workflow?
 
 A chaos workflow is much more than a simple chaos experiment. It supports the user in defining the expected result, observing the result, analysing the overall system behaviour, and in the decision-making process if the system needs to be tuned for improving the resilience.
 LitmusChaos provides necessary infrastructure to develop, use, and manage chaos workflows for a typical development or operations team. Teaming and GitOps features of Litmus help greatly to collaborate the chaos workflows management within the teams or software organisations.
