fix broken links

dmesser · dmesser · commit 06a8d68b8299 · 2019-12-02T15:07:53.000+01:00
Signed-off-by: dmesser &lt;dmesser@redhat.com&gt;
diff --git a/docs/discover-operator-presence.md b/docs/discover-operator-presence.md
@@ -6,7 +6,7 @@ Checking the presence of custom installed operators in the cluster is simply a m
 associated with it that that contains all the details of the operator. Running `kubectl get csvs -A`
 would return all CSVs across all namespaces and provide a high-level view of all custom installed operators. 
 
-If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](https://) to debug your installation.  
+If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](troubleshooting.md) to debug your installation.  
 
 ## Finding available operators
 Operators are available from a variety of sources, or catalogs. Some catalogs are bundled in the default installation of
diff --git a/docs/how-do-i-install-my-operator-with-olm.md b/docs/how-do-i-install-my-operator-with-olm.md
@@ -1,6 +1,6 @@
 # How do I install my operator with OLM?
 
-[Once you've made your packaged operator available in a catalog](./how-do-i-package-my-operator-for-olm) it will appear in the `packagemanifest` list from which the Operators to install are selected. See [How do I list available Operators](./list-available-operators.md#information-relevant-for-installation) how to retrieve the required information from the `PackageServer` in order start an installation of an Operator.
+[Once you've made your packaged operator available in a catalog](packaging-an-operator.md) it will appear in the `packagemanifest` list from which the Operators to install are selected. See [How do I list available Operators](list-available-operators.md#information-relevant-for-installation) how to retrieve the required information from the `PackageServer` in order start an installation of an Operator.
 
 ## Install with automatic updates enabled
 
@@ -121,7 +121,7 @@ NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
 my-operator             1/1     1            1           9m48s
 ```
 
-If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](https://) to debug your installation.
+If the ClusterServiceVersion fails to show up or does not reach the `Succeeded` phase, please check the [troubleshooting documentation](troubleshooting.md) to debug your installation.
 
 ## Install with manual updates
 
diff --git a/docs/operator-scoping.md b/docs/operator-scoping.md
@@ -147,7 +147,7 @@ spec:
 
 Any operator tied to this `OperatorGroup` will now be confined to the permission(s) granted to the specified `ServiceAccount`. If the operator asks for permission(s) that are outside the scope of the `ServiceAccount` the install will fail with appropriate error(s).
 
-An example of scoping an operator can be found [here]("https://operator-framework.github.io/olm-book/docs/how-do-i-scope-down-an-operator).
+An example of scoping an operator can be found [here](./).
 
 ### Configuring the End User Experience
 
diff --git a/docs/packaging-an-operator.md b/docs/packaging-an-operator.md
@@ -27,7 +27,7 @@ These manifests consist of:
 
 Building a minimal `ClusterServiceVersion` from these requires transplanting the contents of the Operator definition and the RBAC definitions into a CSV. Together, your CSV and CRDs will form the package that you give to OLM to install an operator.
 
-#### Basic Metadata [Optional]
+#### Basic Metadata \[Optional\]
 
 Let's start with a CSV that only contains some descriptive metadata:
 
@@ -55,7 +55,7 @@ spec:
 
 Most of these fields are optional, but they provide an opportunity to describe your operator to potential or current users.
 
-#### Installation Metadata [Required]
+#### Installation Metadata \[Required\]
 
 The next section to add to the CSV is the Install Strategy - this tells OLM about the runtime components of your operator and their requirements. 
 
@@ -139,7 +139,7 @@ If you have an existing CSV `csv.yaml` (refer to the example from Basic Metadata
 $ faq -f yaml -o yaml --slurp '.[0].spec.install = {strategy: "deployment", spec:{ deployments: [{name: .[1].metadata.name, template: .[1].spec }], permissions: [{serviceAccountName: .[3].metadata.name, rules: .[2].rules }]}} | .[0]' csv.yaml operator.yaml role.yaml service_account.yaml
 ```
 
-#### Defining APIs [Required]
+#### Defining APIs \[Required\]
 
 By definition, operators are programs that can talk to the Kubernetes API. Often, they are also programs that *extend* the Kubernetes API, by providing an interface via `CustomResourceDefinition`s or, less frequently, `APIService`s. 
 
@@ -204,7 +204,7 @@ spec:
       kind: Memcached
 ```
 
-##### NativeAPIs [recommended]
+##### NativeAPIs \[recommended\]
 
 There are often cases where you wish to depend on an API that is either provided natively by the platform (i.e. `Pod`) or sometimes by another operator that is outside the control of OLM.
 
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
@@ -88,7 +88,7 @@ If the OLM operator encounters an unrecoverable error when attempting to install
 
 >Note: It is possible that the Status is missing, which suggests that the OLM operator is encountering an issue when processing the `CSV` in a very early stage. You should respond by reviewing the logs of the OLM operator.
 
-You should typically pay special attention to the information within the `status.reason` and `status.message` fields. Please look in the [#failed-csv-reasons]
+You should typically pay special attention to the information within the `status.reason` and `status.message` fields. Please look in the [#Failed CSV reasons](#failed-csv-reasons) section.
 
 If the `Status` block does not provide enough information, check the [OLM operator's logs](#how-to-view-the-olm-operator-logs).
 
