fix: naming (#77)

docs/apl/introduction.md

@@ -6,8 +6,8 @@ sidebar_label: Introduction
 
 ## Application Platform for LKE
 
-Application Platform for LKE (you will see us use the abbreviation `APL`) is a platform that combines developer and operations-centric tools, automation and self-service to streamline the application lifecycle when using Kubernetes. From development to delivery to management of containerized application workloads.
+Application Platform for LKE is a platform that combines developer and operations-centric tools, automation and self-service to streamline the application lifecycle when using Kubernetes. From development to delivery to management of containerized application workloads.
 
-Application Platform for LKE connects many of the technologies found in the Cloud Native Computing Foundation (CNCF) landscape in a way to provide direct value. No more re-inventing the wheel when building and maintaining your own Kubernetes based platform or bespoke stack.
+The platform connects many of the technologies found in the Cloud Native Computing Foundation (CNCF) landscape in a way to provide direct value. No more re-inventing the wheel when building and maintaining your own Kubernetes based platform or bespoke stack.
 
 Application Platform for LKE is optimized to run on Linode Kubernetes Engine (LKE), but can also (manually) be installed on any other [conformant Kubernetes cluster](https://www.cncf.io/training/certification/software-conformance/).

docs/apps/alertmanager.md

@@ -12,7 +12,7 @@ Alertmanager is configured to use the global values found under settings' [alert
 
 A team may decide to override some or all of them, in order to have alerts sent to their own endpoints. Self-service rights to alerting must be enabled for the team (enabled by default for all teams). Each Team can enable a dedicated alertmanager instance.
 
-APL supports the following receivers:
+The following receivers are supported:
 
 - `Slack`
 - `Microsoft Teams`

docs/apps/argocd.md

@@ -6,17 +6,17 @@ sidebar_label: Argo CD
 
 ## About
 
-Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD is configured by APL to use the SSO provided by keycloak, and maps APL groups to Argo CD roles. The `otomi-admin` role is made super admin within Argo CD. The team-admin role has access to Argo CD and is admin of all team projects. Members of team roles are only allowed to administer their own projects. All Teams will automatically get access to a Git repo, and Argo CD is configured to listen to this repo. All a team has to do is to fill their repo with intended state, commit, and automation takes care of the rest.
+Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD is configured to use the SSO provided by Keycloak, and maps groups to Argo CD roles. The `platform-admins` role is made super admin within Argo CD. The platform-admins role has access to Argo CD and is admin of all team projects. Members of team roles are only allowed to administer their own projects. All Teams will automatically get access to a Git repo, and Argo CD is configured to listen to this repo. All a team has to do is to fill their repo with intended state, commit, and automation takes care of the rest.
 
 Teams will be be automatically given a git repository in Gitea named `team-$teamId-argocd`, and Argo CD is automatically configured to access the repository and sync. All that is left to do is for a team-admin (or team member with self-service rights) to fill their repository with intended state and commit.
 
-Argo CD is configured to use the SSO provided by keycloak, and maps APL groups to Argo CD roles:
+Argo CD is configured to use the SSO provided by keycloak, and maps groups to Argo CD roles:
 
-- Group `otomi-admin` is made super admin within Argo CD
+- Group `platform-admins` is made super admin within Argo CD
 
-- Group team-admin has access to, and is admin of all team projects
+- Group team-admins has access, and is admin of all Team projects
 
-- Team members are only allowed access to, and administer their own projects
+- Team members are only allowed access and to administer their own projects
 
 Teams will be be automatically given a git repository in Gitea named `team-$teamId-argocd`, and Argo CD is automatically configured to access the repository and sync. All that is left to do is Teams to fill their repository with the intended state (manifests) and commit.
 

docs/apps/certmanager.md

@@ -6,12 +6,12 @@ sidebar_label: Cert-Manager
 
 ## About
 
-Cert-Manager is used by APL to automatically create and rotate wildcard TLS certificates for service endpoints. You may bring your own CA, or let APL create one for you. If you bring your own trusted wildcard certificate, then cert-manager will not manage this certificate.
+Cert-Manager is used to automatically create and rotate wildcard TLS certificates for service endpoints. You may bring your own CA, or otherwise one is created for you. If you bring your own trusted wildcard certificate, then cert-manager will not manage this certificate.
 
 :::info
 The wildcard certificate must be valid for the following domain `*.<cluster.domainSuffix>`, where the value of `<cluster.domainSuffix>` comes from the cluster.yaml file.
 :::
 
 :::info
-Setting Cert-Manager to use Letsencrypt requires DNS availability of the requesting domains, and forces Otomi to install [ExternalDNS](external-dns.md). Because a lot of DNS settings are used by other APL contexts, all DNS configuration can be found [here](../for-ops/console/settings/dns.md).
+Setting Cert-Manager to use Letsencrypt requires DNS availability of the requesting domains, and forces Otomi to install [ExternalDNS](external-dns.md). Because a lot of DNS settings are used by other contexts, all DNS configuration can be found [here](../for-ops/console/settings/dns.md).
 :::                                                                                                                                                                                                                                                      |

docs/apps/cloudnativepg.md

@@ -6,4 +6,4 @@ sidebar_label: Cloudnative Postgresql
 
 ## About
 
-CloudNativePG is used by APL to provide PostgreSQL database for APL applications like Harbor and Keycloak. Configure a storage provider to store backups in (external) object storage. Backups can be enabled in the settings.
+CloudNativePG is used to provide PostgreSQL database for integrated applications like Harbor and Keycloak. Configure a storage provider to store backups in (external) object storage. Backups can be enabled in the settings.

docs/apps/external-dns.md

@@ -6,12 +6,12 @@ sidebar_label: ExternalDNS
 
 ## About
 
-ExternalDNS is required to make public service domains accessible by registering them with APL's front loadbalancer CNAME or IP address. When it is not enabled (default) APL will instead rely on [nip.io](https://nip.io) to create host names for all services.
+ExternalDNS is required to make public service domains accessible by registering them with the loadbalancer IP address. When externalDNS is not enabled, [nip.io](https://nip.io) will be used.
 
 The use of ExternalDNS is a prerequisite for using the following features:
 
 - Harbor private registries for teams.
 
-- The Builds self-service feature in APL Console (relies on Harbor).
+- The Builds self-service feature in the Console (relies on Harbor).
 
-- The Projects self-service feature in APL Console (relies on Harbor).
+- The Projects self-service feature in the Console (relies on Harbor).

docs/apps/falco.md

@@ -18,4 +18,4 @@ Before activating Falco, please first check which [Driver](https://falco.org/doc
 
 If you know which driver should be used, activate Falco, go to the `Values`, add the `Driver` and submit changes. Now `Deploy Changes`.
 
-When Falco is installed, APL will add a set of rules to `white-list` all known behaviour. These rules are added using the Raw Values.  
+When Falco is installed, a set of rules to `white-list` all known behaviour is added. These rules are added using the Raw Values.  

docs/apps/gitea.md

@@ -6,4 +6,4 @@ sidebar_label: Gitea
 
 ## About
 
-Gitea is a community managed lightweight code hosting solution written in Go. Because APL uses Tekton to deploy changes to the values repo, it needs a git hosting solution. When no source control is configured, APL will deploy Gitea for Tekton to target as a git repo. Gitea may be used for other purposes, and is especially useful in combination with Tekton as a CI/CD solution. Just like APL uses it.
+Gitea is a community managed lightweight code hosting solution written in Go. Because Tekton is used to deploy changes to the values repo, it needs a git hosting solution. Gitea is used to host all of the internal Git repositories used by the platform and can also be used for other purposes.

docs/apps/grafana.md

@@ -6,4 +6,4 @@ sidebar_label: Grafana
 
 ## About
 
-APL uses Grafana to visualize [Prometheus](prometheus.md) metrics and [Loki](loki.md) logs. Team members are automatically given `Editor` role, while admins are also given `Admin` role. It is possible to make configuration changes directly in Grafana, but only to non-conflicting settings. Data sources are preconfigured and must not be edited as changes will be lost when Grafana is redeployed.
+Grafana is used to visualize [Prometheus](prometheus.md) metrics and [Loki](loki.md) logs. Team members are automatically given `Editor` role, while admins are also given `Admin` role. It is possible to make configuration changes directly in Grafana, but only to non-conflicting settings. Data sources are preconfigured and must not be edited as changes will be lost when Grafana is redeployed.

docs/apps/harbor.md

@@ -8,7 +8,7 @@ sidebar_label: Harbor
 
 Harbor is an open-source registry that secures artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud-native compute platforms like Kubernetes. (source: https://goharbor.io/)
 
-APL automates the following Harbor maintanace tasks:
+The following Harbor maintenance tasks are automated:
 
 - Creating a project in Harbor for each team.
 

docs/apps/ingress-nginx.md

@@ -6,7 +6,7 @@ sidebar_label: Ingress-nginx
 
 ## About
 
-Ingress NGINX is the default ingress controller in APL and part of the core setup (this means it is not possible use another controller within APL).
+Ingress NGINX is the default ingress controller and part of the core setup.
 
 ### Using the OWASP rule set
 

docs/apps/istio.md

@@ -6,7 +6,7 @@ sidebar_label: Istio
 
 ## About
 
-Istio is installed by APL to deliver the following capabilities:
+Istio is installed to deliver the following capabilities:
 
 - mTLS enforcement for all traffic that is deemed compromisable.
 

docs/apps/jaeger.md

@@ -6,4 +6,4 @@ sidebar_label: Jaeger
 
 ## About
 
-Jaeger can be activated by APL to gain tracing insights on its network traffic. It runs in anonymous mode and each authenticated user is given the same authorization, allowing them to see everything. In the future this may be limited according to scope such as role and teams.
+Jaeger can be activated to gain tracing insights on its network traffic. It runs in anonymous mode and each authenticated user is given the same authorization, allowing them to see everything. In the future this may be limited according to scope such as role and teams.

docs/apps/keycloak.md

@@ -6,15 +6,15 @@ sidebar_label: Keycloak
 
 ## About
 
-The SSO login page for APL is served by Keycloak. It is used as an identity broker or provider for all APL integrated applications. Keycloak is configured with mappers that normalize incoming identities from an IDP to have predictable claims format to be used by APL applications.
+The SSO login page for all platform services (like the Console) is served by Keycloak. It is used as an identity broker or provider for all integrated applications. Keycloak is configured with mappers that normalize incoming identities from an IDP to have predictable claims format to be used by integrated applications.
 
 Keycloak is automatically configured with 3 roles:
 
-- `otomi-admin`: super admin role for all platform configuration and core applications.
+- `platform-admins`: super admin role for all platform configuration and core applications.
 
-- `team-admin`: team admin role to manage teams and users.
+- `team-admins`: team admin role to manage teams and users.
 
-- `team`: team role for team members.
+- `team-members`: team role for team members.
 
 Group (team) membership is reflected in the user's 'groups' claim. When this authorization configuration is useful to their own built applications, teams can directly use Keycloak's provided groups and roles claims. There is no need for a client or token validation, as that has been done by the platform. They can do so by turning on the "Authenticate with Single Sign On" checkbox. This then limits the application access to only allow the members of the team.
 

docs/apps/kiali.md

@@ -6,4 +6,4 @@ sidebar_label: Kiali
 
 ## About
 
-Kiali can be activated in APL to gain observability insights on its network traffic. It runs in anonymous mode and each authenticated user is given the same authorization, allowing them to see everything.
+Kiali can be activated to gain insights into Istio. It runs in anonymous mode and each authenticated administrator is given the same authorization, allowing them to see everything.

docs/apps/knative.md

@@ -6,4 +6,4 @@ sidebar_label: Knative
 
 ## About
 
-Knative can be activated in APL to deliver Container-as-a-Service (CaaS) functionality with scale-to-zero possibility. It can be compared to Functions-as-a-service (FaaS) but is container oriented, and takes only one manifest to configure an autoscaling service based on a container image of choice. APL uses Istio Virtual Services under the hood to route traffic coming in for a public domain to its backing Knative Service, allowing to set a custom domain.
+Knative can be activated to deliver Container-as-a-Service (CaaS) functionality with scale-to-zero possibility. It can be compared to Functions-as-a-service (FaaS) but is container oriented, and takes only one manifest to configure an autoscaling service based on a container image of choice. Istio Virtual Services are used to route traffic for a public domain to its backing Knative Service.

docs/apps/loki.md

@@ -6,16 +6,4 @@ sidebar_label: Loki
 
 ## About
 
-Loki aggregates all the container logs from the platform and stores them in a storage endpoint of choice (defaults to PVC). By default APL will split logs from team namespaces and make them available only to team members. APL splits logs per team, installs a dedicated Grafana instance per team and configures authentication for Grafana to allow access for team members only.
-
-## Known issues
-
-### Time Range does not show all data
-
-Unfortunately the Grafana team has not yet solved their long running problems with their LogQL interface. Instead of providing paginated queries to Loki, it is needed to provide a "line limit" by the user manually.
-
-In a data driven application that has pagination, when a user selects a time window for a data query, the user will not have to provide additional information to perform that query. The UI application takes responsibility for instrumenting the query towards its data backend. It should thus load & render the results either through pagination or by scrolling the time range into view.
-
-**Solution:**
-
-When you don't see enough data, try increasing the line limit. The maximum is configurable in the Loki values.
+Loki aggregates all the container logs from the platform and stores them in a storage endpoint of choice (defaults to PVC). By default logs from Team namespaces are split and available to team members only.

docs/apps/sealedsecrets.md

@@ -14,7 +14,7 @@ You can use your certificates for the disaster recovery purpose. Please make sur
 
 While the controller generates its own certificates upon deployment, you also have the option to bring your own certificates. This allows the controller to consume certificates from a secret labeled with `sealedsecrets.bitnami.com/sealed-secrets-key=active`. The Secret should reside in the `sealed-secrets` namespace, which must be the same as the controller's namespace. You can have multiple secrets with this label.
 
-To configure BYO certificates, add the following to the `values.yaml` when installing APL:
+To configure BYO certificates, add the following to the `values.yaml`:
 
 ```yaml
 apps:

docs/apps/tekton.md

@@ -6,13 +6,13 @@ sidebar_label: Tekton
 
 ## About
 
-Tekton is used in APL for the Builds self-service. When a Build is created, APL generates the Tekton Pipeline and Pipelinerun resources. There are 2 pipeline types:
+Tekton is used for the Builds self-service feature. When a Build is created, the Tekton Pipeline and Pipelinerun resources are created automatically. There are 2 pipeline types:
 
 - `Docker` for building images based on a Dockerfile
 
 - `Buildpacks` for building images using buildpacks
 
-When Tekton is activated, APL will add 4 Tekton tasks to the team's namespace:
+When Tekton is activated, 4 Tekton tasks will be added to the Team's namespace:
 
 1. [`buildpacks`](https://github.com/tektoncd/catalog/tree/main/task/buildpacks/0.6)
 
@@ -25,13 +25,13 @@ When Tekton is activated, APL will add 4 Tekton tasks to the team's namespace:
 
 and use them in the Build pipelines.
 
-When APL generates the manifest resources for the pipeline and the pipelinerun, the pipelinerun will automatically run the pipeline once. Use the following command to check if the status of the pipelinerun:
+When the manifest for the pipeline and the pipelinerun are applied, the pipelinerun will automatically run the pipeline once. Use the following command to check if the status of the pipelinerun:
 
 ```
 tkn pipelineruns logs  <name-of-the-pipelinerun> -n team-<team name>
 ```
 
-If the build is changed in APL, the pipelinerun will not be re-started. Use the following command to start the pipeline after a change:
+If the Build is changed the pipelinerun will not be re-started. Use the following command to start the pipeline after a change:
 
 ```
 tkn pipeline start <name-of-the-pipeline>  --use-pipelinerun <name-of-the-pipelinerun>  -n team-<team name>

docs/for-devs/console/builds.md

@@ -6,7 +6,7 @@ sidebar_label: Builds
 
 <!-- ![Console: new service](img/team-builds.png) -->
 
-A Build in APL is a self-service feature for building OCI compliant images based on application source code and store the image in a private Team registry in Harbor.
+A Build is a self-service feature for building OCI compliant images based on application source code and store the image in a private Team registry in Harbor.
 
 :::info
 Ask your platform administrator to activate the Harbor App to use this feature.
@@ -75,7 +75,7 @@ To see the more status details of the build, click on the `PipelineRun` link of
 
 ### Configure a webhook for the Git repo in Gitea
 
-1. In APL Console, click on `Apps` in the left menu and then open `Gitea`
+1. In the Console, click on `Apps` in the left menu and then open `Gitea`
 
 2. In the top menu of Gitea, click on `Explore` and then on the `green` repo
 
@@ -89,7 +89,7 @@ To see the more status details of the build, click on the `PipelineRun` link of
 
 ### Expose the trigger listener publicly
 
-When using an external (private) Git repository, the trigger event listener that is created by APL can also be exposed publicly. To expose the event listener publicly:
+When using an external (private) Git repository, the trigger event listener that is created can also be exposed publicly. To expose the event listener publicly:
 
 1. Go to Services