Rework of doc menus and it's locations

New structure of the menus to be more user friendly.

Signed-off-by: Michal Pryc <mpryc@redhat.com>

docs/Architecture.md

@@ -17,7 +17,7 @@ _Metrics_
 e.g. deploy_time, commit_time, failure_creation, failure_resolution
 
 _Measures_
-: Metrics calculated to represent an [outcome](philosophy/outcomes/index.md). Each outcome is made measurable by a set of representative measures.
+: Metrics calculated to represent an [outcome](../philosophy/outcomes/Overview/). Each outcome is made measurable by a set of representative measures.
 e.g. Lead Time for Change, Deployment Frequency, Mean Time to Restore, Change Failure Rate
 
 ## Basic Architecture and Components

docs/Development.md

@@ -15,7 +15,7 @@ This track is focused around the development of custom [Prometheus exporters](ht
 
 We use [Helm](https://helm.sh) to provide an automated deployment and configuration experience for Pelorus. We are always doing work to cover more and more complex use cases with our helm charts. In order to be able to effectively contribute to these charts, you'll need a cluster that satisfies all of the installation prerequisites for Pelorus.
 
-See the [Install guide](Install.md) for more details on that.
+See the [Install guide](../GettingStarted/Installation/) for more details on that.
 
 Currently we have two charts:
 
@@ -52,7 +52,7 @@ or bump specific charts with shell script:
 
 ## Dashboard Development
 
-We are continually doing work to enhance and bugfix the Pelorus dashboards. Doing so requires a complete Pelorus stack, including all exporters required to populate a given dashboard. See the [Outcomes (Dashboards)](philosophy/outcomes/index.md) user guide for that information.
+We are continually doing work to enhance and bugfix the Pelorus dashboards. Doing so requires a complete Pelorus stack, including all exporters required to populate a given dashboard. See the [Outcomes (Dashboards)](../philosophy/outcomes/Overview/) user guide for that information.
 
 To effectively do dashboard development, you'll likely need at least two browser windows open, one with Grafana, and another with Prometheus for testing queries. Since our dashboards are imported to Grafana via the Grafana Operator, they get imported in read-only mode. Because of this, you'll need to make a copy of it for development purposes.
 
@@ -237,7 +237,7 @@ Running an exporter on your local machine should follow this process:
 
         . .venv/bin/activate
 
-3. Set any environment variables required (or desired) for the given exporter (see [Configuring Exporters](Configuration.md#configuring-exporters) to see supported variables).
+3. Set any environment variables required (or desired) for the given exporter (see [Configuring Exporters](../GettingStarted/configuration/PelorusExporters/) to see supported variables).
 
         export LOG_LEVEL=debug
         export TOKEN=xxxx
@@ -292,7 +292,7 @@ Checkout the PR on top of your fork.
 
 1. [Checkout](#checkout) the PR on top of your fork.
 
-2. [Install Pelorus](Install.md) from checked out fork/branch.
+2. [Install Pelorus](../GettingStarted/Installation/) from checked out fork/branch.
 
     **NOTE:**
 
@@ -333,15 +333,15 @@ Each PR runs exporter tests in the CI systems, however those changes can be test
             coverage report
 
 
-5. Gather necessary [configuration information](Configuration.md#configuring-exporters).
+5. Gather necessary [configuration information](../GettingStarted/configuration/PelorusExporters/).
 6. [Run exporter locally](#running-locally). You can do this either via the command line, or use the provided [VSCode debug confuration](#ide-setup-vscode) to run it in your IDE Debugger.
 7. Once exporter is running, you can test it via a simple `curl localhost:8080`. You should be validating that:
     1. You get a valid response with metrics.
     1. Confirm the format of expected metrics.
 
 ### Helm Install changes
 
-For testing changes to the helm chart, you should just follow the [standard install process](Install.md), then verify that:
+For testing changes to the helm chart, you should just follow the [standard install process](../GettingStarted/Installation/#helm-charts), then verify that:
 
 * All expected pods are running and healthy
 * Any expected behavior changes mentioned in the PR can be observed.
@@ -399,4 +399,4 @@ rm -rf .cache && mkdocs serve
 to fix it.
 
 
-The mkdocs config is controlled by the `mkdocs.yml` file in the root of this project. All of the documents that will be served are in the [/docs](/docs) folder.
+The mkdocs config is controlled by the `mkdocs.yml` file in the root of this project. All of the documents that will be served are in the [/docs](https://github.com/konveyor/pelorus/tree/master/docs) folder.

docs/Install.md → docs/GettingStarted/Installation.md

@@ -34,32 +34,32 @@ Before deploying Pelorus, the following tools are necessary
 ### Installing Operator
 
 After logging in to the OpenShift Web console select OperatorHub from the Operators menu and search for Pelorus Operator by typing DORA, Dora metrics or Pelorus in the search field:
-  ![1_operator_install_step](img/1_operator_install_step.png)
+  ![1_operator_install_step](../img/1_operator_install_step.png)
 
 Next click on Install in the left top corner:
-  ![2_operator_install_step](img/2_operator_install_step.png)
+  ![2_operator_install_step](../img/2_operator_install_step.png)
 
 You can select OpenShift namespace to which Pelorus will be installed, then click Install. We recommend using default one, which is **pelorus**. This creates Pelorus Subscription in the given namespace.
-  ![3_operator_install_step](img/3_operator_install_step.png)
+  ![3_operator_install_step](../img/3_operator_install_step.png)
 
 Verify that Pelorus, Grafana and Prometheus Operators are installed successfully by checking them under Installed Operators submenu:
-  ![4_operator_install_step](img/4_operator_install_step.png)
+  ![4_operator_install_step](../img/4_operator_install_step.png)
 
 ### Creating Pelorus instance
 
 >**Note:** Currently it is possible to create only one instance of Pelorus per cluster.
 
 Click on the Pelorus Operator from the [Installing Operator](#installing-operator) last step and then on the "Create instance" link:
-  ![5_operator_install_step](img/5_operator_install_step.png)
+  ![5_operator_install_step](../img/5_operator_install_step.png)
 
 
-** Note:** See the [Configuration Guide](Configuration.md) for more information on exporters and the [Configuration2 Guide](configuration2.md) to understand Pelorus core stack options before continuing.
+** Note:** See the [Pelorus Exporters Configuration Guide](../configuration/PelorusExporters/) for more information on exporters and the [Pelorus Core Configuration Guide](../configuration/PelorusCore/) to understand Pelorus core stack options before continuing.
 
 Click on the `YAML view`, which will open sample Pelorus object YAML, that should be adopted to the application workflow configuration of exporters, which are placed under `instances:` section and eventually additional configuration for the Pelorus core stack under `spec:` and click on the Create button:
-  ![6_operator_install_step](img/6_operator_install_step.png)
+  ![6_operator_install_step](../img/6_operator_install_step.png)
 
 Verify Pelorus application deployment by selecting Pelorus tab from the Pelorus Operator view and ensuring the application has `Deployed` status. You may want to check more information about the Pelorus application deployment by clicking on the application name in the following picture `pelorus-sample`:
-  ![7_operator_install_step](img/7_operator_install_step.png)
+  ![7_operator_install_step](../img/7_operator_install_step.png)
 
 ## OpenShift Command Line Tool
 
@@ -135,7 +135,7 @@ Verify the ClusterServiceVersion (csv) for Pelorus Operator together with Grafan
 
 The Pelorus object YAML file requires specific to the application workflow configuration of exporters that are placed under `instances:` section and eventually additional configuration for the Pelorus core stack under `spec:`.
 
-See the [Configuration Guide](Configuration.md) for more information on exporters and the [Configuration2 Guide](configuration2.md) to understand Pelorus core stack options.
+See the [Pelorus Exporters Configuration Guide](../configuration/PelorusExporters/) for more information on exporters and the [Pelorus Core Configuration Guide](../configuration/PelorusCore/) to understand Pelorus core stack options.
 
 *(Example)* Create Pelorus configuration object YAML file. In this example with two enabled exporters `committime-exporter` and `deploytime-exporter`, without prometheus persistent storage:
   ```shell
@@ -264,7 +264,7 @@ In a few seconds, you will see a number of resourced get created. The above comm
     * A `Grafana` instance
     * A `ServiceMonitor` instance for scraping the Pelorus exporters.
     * A `GrafanaDatasource` pointing to Prometheus.
-    * A set of `GrafanaDashboards`. See the [Outcomes (Dashboards) documentation](philosophy/outcomes/index.md) for more details.
+    * A set of `GrafanaDashboards`. See the [Outcomes (Dashboards) documentation](../../philosophy/outcomes/SoftwareDeliveryPerformance/) for more details.
 * The following exporters:
     * Deploy Time
     * Commit Time
@@ -274,11 +274,11 @@ To check this, run
 oc get all --namespace pelorus
 ```
 
-From here, some additional configuration is required in order to deploy other exporters. See the [Configuration Guide](Configuration.md) for more information on exporters.
+From here, some additional configuration is required in order to deploy other exporters. See the [Pelorus Exporters Configuration Guide](../configuration/PelorusExporters/) for more information on exporters.
 
-You may also want to enabled other features for the core stack. See the [Configuration2 Guide](configuration2.md) to understand those options.
+You may also want to enabled other features for the core stack. See the [Pelorus Core Configuration Guide](../configuration/PelorusCore/) to understand those options.
 
-To understand how to set up an application to Pelorus to watch, see [QuickStart tutorial](Demo.md).
+To understand how to set up an application to Pelorus to watch, see [QuickStart tutorial](../QuickstartTutorial/).
 
 ### Uninstalling
 
@@ -292,4 +292,4 @@ helm uninstall operators --namespace pelorus
 If Pelorus was deployed with PVCs, you may want to delete them, because helm uninstall will not remove PVCs. To delete them, run
 ```
 oc delete pvc --namespace pelorus $(oc get pvc --namespace pelorus -o name)
-```
+```

docs/Demo.md → docs/GettingStarted/QuickstartTutorial.md

@@ -1,6 +1,6 @@
 # Pelorus Demo
 
-For Pelorus installation to monitor your application's workflow, please skip this Demo and jump straight to the [Installation](Install.md) and [Configuration](configuration2.md) part of the documentation.
+For Pelorus installation to monitor your application's workflow, please skip this Demo and jump straight to the [Installation](../Installation/) and [Configuration](../configuration/PelorusCore/) part of the documentation.
 
 In this demo, you will
 
@@ -14,13 +14,13 @@ To do so, you will
 * Create new commits and issues
 * Watch as the metrics and trends change as new versions roll out**\***
 
-> **Note:** More information about the four key DORA metrics can be found in our [Outcomes documentation](./philosophy/outcomes/index.md).
+> **Note:** More information about the four key DORA metrics can be found in our [Outcomes documentation](../../philosophy/outcomes/Overview/).
 
 ## Lead Time for Change and Deployment Frequency
 
 In this section you see how Pelorus measures two DORA metrics: **Lead time for change** and **Deployment frequency**.
 
-![dora_lead_deployment](img/dora_metrics1.png)
+![dora_lead_deployment](../img/dora_metrics1.png)
 
 ### Install the sample application
 
@@ -52,7 +52,7 @@ oc get buildconfig.build.openshift.io/todolist --namespace mongo-persistent -o=g
 
 ### Pelorus configuration
 
-After following [Installation guide](Install.md), copy `values.yaml` file to `/var/tmp/values.yaml`, by running
+After following [Installation guide](../Installation/), copy `values.yaml` file to `/var/tmp/values.yaml`, by running
 ```
 cp charts/pelorus/values.yaml /var/tmp/
 ```
@@ -98,7 +98,7 @@ Navigate to **"pelorus / Software Delivery Performance - By App"** and select th
 
 You should now see at least one measurement for **Lead Time for Change** and **Deployment Frequency**, like in the following image.
 
-![gnome-shell-screenshot-3zh4l2](img/initial_measurement.png)
+![gnome-shell-screenshot-3zh4l2](../img/initial_measurement.png)
 
 ### Update application
 
@@ -138,7 +138,7 @@ oc get route todolist-route --namespace mongo-persistent -o=go-template='http://
 
 It should look like in the following image.
 
-![todolist](img/todolist_orig.png)
+![todolist](../img/todolist_orig.png)
 
 The text "Enter an activity" does not seem clear, let's change that to "Add a todo", by running
 ```
@@ -156,18 +156,18 @@ Once the commit is pushed to the repository, it will automatically rebuild becau
 
 You will now see that the todolist application starts to rebuild, like in the following image.
 
-![todolist_rebuild](img/todolist_rebuild.png)
+![todolist_rebuild](../img/todolist_rebuild.png)
 
 After it finishes, you can now see on your todolist application the updated text change "Add a todo", like in the following image.
 
-![todolist-fixed](img/todolist_fixed.png)
+![todolist-fixed](../img/todolist_fixed.png)
 
 ### Understand the changes to the Grafana Dashboard
 
 Navigate to **"pelorus / Software Delivery Performance - By App"** and set the interval to 15 minutes.
 Pelorus will now read the updated commit and register a new deploytime.  You should now see a total for two deployments, like in the following image.
 
-![First-Update](img/todolist_update1.png)
+![First-Update](../img/todolist_update1.png)
 
 The **Lead Time for Change** should initially go down as we just pushed a commit.  The time difference between changes to the original git repository and your personal forked repo will most likely cause this metric to go down.
 
@@ -177,7 +177,7 @@ There have been two deployments since this demonstration was started, the initia
 
 In this section you see how Pelorus measures the last two DORA metrics: **Mean time to recovery** and **Change failure rate**.
 
-![dora_fail_recover](img/dora_metrics2.png)
+![dora_fail_recover](../img/dora_metrics2.png)
 
 It is necessary to have Github issues enabled in your fork of the mig-apps-demo repository (visit settings to enable it).
 
@@ -242,27 +242,27 @@ Pelorus will utilize two labels to determine if a GitHub issue is associated wit
 
 Navigate to https://github.com/your_org/mig-demo-apps/labels and check/create the following Github issue labels exists, like in the following image.
 
-![github_start](img/github_issues_setup.png)
+![github_start](../img/github_issues_setup.png)
 
 Now, we will create an issue in Github and set the appropriate labels. Pelorus will register an issue as a deployment failure only if it is labeled as a `bug` and `app.kubernetes.io/name=todolist` (our application name).
 
 Create a Github issue and label it appropriately to register a failure, like in the following image.
 
-![github_issue1](img/github_issue_1.png)
+![github_issue1](../img/github_issue_1.png)
 
 Refresh the Grafana dashboard and you should see the Change Failure Rate go up.
 
-![change_failure_rate_1](img/change_failure_rate_1.png)
+![change_failure_rate_1](../img/change_failure_rate_1.png)
 
 Now, let's create a non critical bug: a bug that does not indicate a deployment failure in your todolist application.
 
 Create another Github issue and add the bug label, however do **not** add the application label.
 
-![issue_untagged](img/issue_2_non_deployment.png)
+![issue_untagged](../img/issue_2_non_deployment.png)
 
 Now, let's resolve issue #1 and see how that impacts our `Failure Rate` and the `Mean Time to Restore`.
 
-![issue_close](img/github_issue_1_close.png)
+![issue_close](../img/github_issue_1_close.png)
 
 Check the output from the failure exporter again, by running
 ```
@@ -276,7 +276,7 @@ Notice the fields `failure_creation_timestamp` and `failure_resolution_timestamp
 
 Now, we should also have data in the `Mean Time to Restore` metric in Grafana dashboard, like in the following image.
 
-![mean_time_to_restore](img/mean_time_to_restore.png)
+![mean_time_to_restore](../img/mean_time_to_restore.png)
 
 **Mean Time to Restore** measures how long it takes to restore the service when an incident occurs.
 

docs/Noobaa.md → docs/GettingStarted/configuration/Noobaa.md

@@ -2,7 +2,7 @@
 
 NooBaa is a software-driven data service that provides S3 object-storage interface that we use for testing and development of Pelorus project.
 
-The following is a walkthrough for deploying NooBaa Operator on OpenShift and then configuring Pelorus to consume it as a [Long Term Storage](configuration2.md#configure-long-term-storage-recommended) solution.
+The following is a walkthrough for deploying NooBaa Operator on OpenShift and then configuring Pelorus to consume it as a [Long Term Storage](../ProductionBestPractice/#configure-long-term-storage-recommended) solution.
 
 ## Install NooBaa Operator CLI
 
@@ -105,7 +105,7 @@ noobaa bucket status thanos --namespace pelorus
 
 ## Update Pelorus Configuration
 
-To update our Pelorus stack, follow the instructions provided in the [Long Term Storage](configuration2.md#configure-long-term-storage-recommended).
+To update our Pelorus stack, follow the instructions provided in the [Long Term Storage](../ProductionBestPractice/#configure-long-term-storage-recommended).
 
 Ensure that `<s3 access key>`, `<s3 secret access key>` and the `<bucket name>` are used from the [Deploy NooBaa
 ](#deploy-noobaa) step and `s3.pelorus.svc:443`, which is an `S3 InternalDNS Address` from the `noobaa status --namespace pelorus` command, as bucket access point as in example:

docs/Configuration.md → docs/GettingStarted/configuration/PelorusExporters.md

@@ -406,13 +406,13 @@ Example Github issue:
 
 Create an issue, and create a Github issue label: "app.kubernetes.io/name=todolist".  Here is a working [example](https://github.com/konveyor/mig-demo-apps/issues/82)
 
-![github_issue](img/github_issue.png)
+![github_issue](../../img/github_issue.png)
 
 Jira issue:
 
 In the Jira project issue settings, create a label with the text "app.kubernetes.io/name=todolist". 
 
-![jira_issue](img/jira_issue.png)
+![jira_issue](../../img/jira_issue.png)
 
 ### Annotations and local build support