fix broken links

Signed-off-by: dmesser <dmesser@redhat.com>

Author: dmesser

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](docs/) 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

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](./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](docs/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](docs/troubleshooting.md) to debug your installation.
 
 ## Install with manual updates
 

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](docs/).
 
 ### Configuring the End User Experience
 

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.
 

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).