Merge pull request #722 from sebrandon1/update_tutorial_bash

tutorials: update readability

Author: yuumasato

doc/crds.md

@@ -65,7 +65,7 @@ automatically when the ComplianceOperator starts in order to provide useful defa
 You can inspect the existing `ProfileBundle` objects by calling:
 
 ```
-oc get profilebundle -nopenshift-compliance
+oc get profilebundle -n openshift-compliance
 ```
 
 Note that in case you need to roll back to a known-good content image

doc/remediation-templating.md

@@ -250,6 +250,6 @@ metadata:
 
 The above situation can be caused by the situation where an administrator did not set a value for `sshd_idle_timeout_value` in the TailorProfile before the scan, to find which value is available to set for that variable in order to fix that remediation, an admin can use:
 
-`$ oc describe variable rhcos4-sshd-idle-timeout-value -nopenshift-compliance`
+`$ oc describe variable rhcos4-sshd-idle-timeout-value -n openshift-compliance`
 
 An admin can find a section of value for variable `sshd-idle-timeout-value` to choose from, and they can set that value in a tailored profile to satisfy the `compliance.openshift.io/value-required`. Noted, an admin can also set the variable to any other value besides the section values.

doc/troubleshooting.md

@@ -10,7 +10,7 @@ to a (CRD document)[crds.md] to learn more API objects.
 
    * The Compliance Operator emits Kubernetes events when something
      important happens. You can either view all events in the cluster (`oc get events
-     -nopenshift-compliance`) or events for an object, e.g. for a scan
+     -n openshift-compliance`) or events for an object, e.g. for a scan
      (`oc describe compliancescan/$scan`)
 
    * The Compliance Operator consists of several controllers, roughly

doc/tutorials/workshop/content/exercises/02-installation.md

@@ -11,19 +11,29 @@ not deploying from the source, we're going to be creating several Kubernetes
 objects from manifests in the upstream repository.
 
 Start by creating the `openshift-compliance` namespace:
-```
-$ oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/ns/ns.yaml
-namespace/openshift-compliance created
+
+```bash
+oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/ns/ns.yaml
 ```
 
 We'll be using the OpenShift [Operator Lifecycle Manager](https://docs.openshift.com/container-platform/4.5/operators/understanding_olm/olm-understanding-olm.html)
 so we'll continue by creating several objects that describe the operator for
 the OLM. First, we'll create the `CatalogSource` and verify that it's been
 created successfully:
+
+```bash
+oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/catalog/catalog-source.yaml
 ```
-$ oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/catalog/catalog-source.yaml
+
+```yaml
 catalogsource.operators.coreos.com/compliance-operator created
-$ oc get catalogsource -nopenshift-marketplace
+```
+
+```bash
+oc get catalogsource -n openshift-marketplace
+```
+
+```
 NAME                  DISPLAY                        TYPE   PUBLISHER                                         AGE
 certified-operators   Certified Operators            grpc   Red Hat                                           24m
 community-operators   Community Operators            grpc   Red Hat                                           24m
@@ -36,59 +46,91 @@ The `CatalogSource` represents metadata that OLM can use to discover and
 install Operators. Once the `CatalogSource` is created, we can continue by
 telling OLM that we want to install the Compliance Operator to the `openshift-compliance`
 namespace by creating the `OperatorGroup` and the `Subscription` objects:
+
+```bash
+oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/catalog/operator-group.yaml
 ```
-$ oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/catalog/operator-group.yaml
+
+```yaml
 operatorgroup.operators.coreos.com/compliance-operator created
-$ oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/catalog/subscription.yaml
+```
+
+```bash
+oc create -f https://raw.githubusercontent.com/ComplianceAsCode/compliance-operator/master/config/catalog/subscription.yaml
+```
+
+```yaml
 subscription.operators.coreos.com/compliance-operator-sub created
 ```
 
-The Subscription file can be edited to optionally deploy a custom version,
-see the `startingCSV` attribute in the `config/catalog/subscription.yaml`
-file.
+The Subscription file can be edited to optionally deploy a custom version, see the `startingCSV` attribute in the `config/catalog/subscription.yaml` file.
 
 After a minute or two, the operator should be installed. Verify that the
 Compliance Operator deployment and pods are running:
+
+```bash
+oc get deploy -n openshift-compliance
+oc get pods -n openshift-compliance
 ```
-$ oc get deploy -nopenshift-compliance
-$ oc get pods -nopenshift-compliance
-```
+
 You should see output similar to this one:
+
+```bash
+oc get deploy -n openshift-compliance
+```
+
 ```
-$ oc get deploy -nopenshift-compliance
 NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
 compliance-operator              1/1     1            1           8m9s
 ocp4-openshift-compliance-pp     1/1     1            1           7m22s
 rhcos4-openshift-compliance-pp   1/1     1            1           7m22s
+```
+
+```bash
+oc get pods -n openshift-compliance
+```
 
-$ oc get pods -nopenshift-compliance
+```
 NAME                                             READY   STATUS    RESTARTS   AGE
 compliance-operator-6fb8c75499-wkmjg             1/1     Running   0          8m11s
 ocp4-openshift-compliance-pp-6d45b4664d-ztflt    1/1     Running   0          7m24s
 rhcos4-openshift-compliance-pp-5cd48cff6-98kl2   1/1     Running   0          7m24s
 ```
+
 Note: The `ocp4-openshift-compliance-pp` and the `rhcos4-openshift-compliance-pp` `Deployment` and `Pods` are created
 by the operator and can take up to a minute to appear. The most important
 object to see is the `compliance-operator` deployment and the associated pod.
 
 If the deployment does not appear, check the `ClusterServiceVersion` and
 `InstallationPlan` objects, normally you should see output similar to the
 one below:
+
+```bash
+oc get csv -nopenshift-compliance
+```
+
 ```
-$ oc get csv -nopenshift-compliance
 NAME                          DISPLAY               VERSION   REPLACES   PHASE
 compliance-operator.v1.2.0    Compliance Operator   1.2.0                Succeeded
-$ oc get ip -nopenshift-compliance
+```
+
+```bash
+oc get ip -nopenshift-compliance
+```
+
+```
 NAME            CSV                           APPROVAL    APPROVED
 install-mlxkz   compliance-operator.v1.2.0    Automatic   true
 ```
 
 If the deployment is there, but pods don't appear, check the `Deployment`
 or its `ReplicaSet`:
+
+```bash
+oc describe deploy/compliance-operator -nopenshift-compliance
+oc describe rs -lname=compliance-operator -nopenshift-compliance
 ```
-$ oc describe deploy/compliance-operator -nopenshift-compliance
-$ oc describe rs -lname=compliance-operator -nopenshift-compliance
-```
+
 Any errors would usually surface as `Events` attached to the respective
 Kubernetes objects.
 

doc/tutorials/workshop/content/exercises/03-creating-your-first-scan.md

@@ -75,7 +75,7 @@ the result of the content parsing.
 
 Several `Profile` objects are parsed out of each bundle, for the `rhcos4` bundle we'd have:
 ```
-$ oc get profile.compliance -lcompliance.openshift.io/profile-bundle=rhcos4  -nopenshift-compliance
+$ oc get profile.compliance -lcompliance.openshift.io/profile-bundle=rhcos4  -n openshift-compliance
 NAME                             AGE
 rhcos4-anssi-bp28-enhanced       19m
 rhcos4-anssi-bp28-high           19m

doc/tutorials/workshop/content/exercises/06-troubleshooting.md

@@ -8,7 +8,7 @@ General tips
 
 * The Compliance Operator emits Kubernetes events when something
   important happens. You can either view all events in the cluster (`oc get events
-  -nopenshift-compliance`) or events for an object, e.g. for a scan
+  -n openshift-compliance`) or events for an object, e.g. for a scan
   (`oc describe compliancescan/$scan`)
 
 * The Compliance Operator consists of several controllers, roughly

doc/usage.md

@@ -583,7 +583,7 @@ spec:
 
 and apply it:
 ```shell
-$ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
+$ oc patch sub compliance-operator -n openshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
 ```
 
 Please note that this only sets the limit for the compliance-operator

tests/data/ocp4-unexistent-resource.xml

@@ -2601,55 +2601,55 @@ configured to false.
         <ocil:boolean_question id="ocil:ssg-controller_service_account_ca_question:question:1">
           <ocil:question_text>To verify that root-ca-file is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["root-ca-file"]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["root-ca-file"]'
 The output should return a configured certificate authority file.
       Is it the case that &lt;tt&gt;root-ca-file&lt;/tt&gt; is not configured&lt;/tt&gt;?
       </ocil:question_text>
         </ocil:boolean_question>
         <ocil:boolean_question id="ocil:ssg-controller_use_service_account_question:question:1">
           <ocil:question_text>To verify that service-account-credentials is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["use-service-account-credentials"]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["use-service-account-credentials"]'
 The value of use-service-account-credentials should be true.
       Is it the case that &lt;tt&gt;use-service-account-credentials&lt;/tt&gt; is set to &lt;tt&gt;false&lt;/tt&gt;?
       </ocil:question_text>
         </ocil:boolean_question>
         <ocil:boolean_question id="ocil:ssg-controller_secure_port_question:question:1">
           <ocil:question_text>To verify that secure-port is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson |   jq -r '.data["config.yaml"]' | jq '.extendedArguments["secure-port"][]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json |   jq -r '.data["config.yaml"]' | jq '.extendedArguments["secure-port"][]'
 Verify that it's using an appropriate port (the value is not 0).
       Is it the case that &lt;tt&gt;secure-port&lt;/tt&gt; is not configured to use a secure port?
       </ocil:question_text>
         </ocil:boolean_question>
         <ocil:boolean_question id="ocil:ssg-controller_service_account_private_key_question:question:1">
           <ocil:question_text>To verify that service-account-private-key-file is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["service-account-private-key-file"]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["service-account-private-key-file"]'
 The output should return a configured private key file.
       Is it the case that &lt;tt&gt;service-account-private-key-file&lt;/tt&gt; does not exist or is configured properly?
       </ocil:question_text>
         </ocil:boolean_question>
         <ocil:boolean_question id="ocil:ssg-controller_insecure_port_disabled_question:question:1">
           <ocil:question_text>To verify that port is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson |   jq -r '.data["config.yaml"]' | jq '.extendedArguments["port"][]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json |   jq -r '.data["config.yaml"]' | jq '.extendedArguments["port"][]'
 Verify that it's disabled (the value is 0).
       Is it the case that &lt;tt&gt;port&lt;/tt&gt; is not disabled?
       </ocil:question_text>
         </ocil:boolean_question>
         <ocil:boolean_question id="ocil:ssg-controller_terminated_pod_gc_threshhold_question:question:1">
           <ocil:question_text>To verify that terminated-pod-gc-threshold is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["terminated-pod-gc-threshold"]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["terminated-pod-gc-threshold"]'
 The returned value of terminated-pod-gc-threshold should be greater than zero.
       Is it the case that &lt;tt&gt;terminated-pod-gc-threshold&lt;/tt&gt; is not enabled?
       </ocil:question_text>
         </ocil:boolean_question>
         <ocil:boolean_question id="ocil:ssg-controller_rotate_kubelet_server_certs_question:question:1">
           <ocil:question_text>To verify that RotateKubeletServerCertificate is configured correctly,
 run the following command:
-$ oc get configmaps config -n openshift-kube-controller-manager -ojson | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["feature-gates"]'
+$ oc get configmaps config -n openshift-kube-controller-manager -o json | jq -r '.data["config.yaml"]' | jq -r '.extendedArguments["feature-gates"]'
 The output should return RotateKubeletServerCertificate=true.
       Is it the case that &lt;tt&gt;RotateKubeletServerCertificate&lt;/tt&gt; argument is set to &lt;tt&gt;false&lt;/tt&gt; in the
 &lt;tt&gt;controllerArguments&lt;/tt&gt; options?