feat: update for 1.0.0

docs/apps/minio.md

@@ -9,4 +9,5 @@ Minio can be enabled to provice an in-cluster S3 compatible Object Store service
 - Loki (for storing logs)
 - Thanos (for storing metrics)
 - Velero (for storing backups)
-- Cloudnative-pg (for storing database backups)
+- Cloudnative-pg (for storing database backups)
+- Tempo (for storing traces)

docs/for-devs/console/builds.md

@@ -16,6 +16,18 @@ Ask you platform administrator to activate Harbor and Tekton to be able to use t
 The otomi Builds feature can only use public code repositories or private repo's in the local Gitea. Images will always be pushed to a registry in the local Harbor.
 :::
 
+## Builds (all)
+
+All known Builds of the team are listed here.
+
+| Property      | Description                                            |
+| ------------- | ------------------------------------------------------ |
+| Build         | The name of the build                                  |
+| Type          | Type of the build. Buildpacks or Docker                |
+| Trigger       | Is trigger configured for the build                    |
+| Tekton        | Link to the PipelineRun of the build in Tekton dashboard |
+| Harbor        | Link to the image in Harbor                            |
+
 ## Create a build
 
 1. Enter a name for the build
@@ -36,18 +48,33 @@ Now choose the type of the build:
 1. Add the URL of the Git repository that contains the application source code
 2. (optional) Change the path of the `Dockerfile`
 3. (optional) Change the revsion. This can be a commit, a tag, or a branch
+4. (optional) Select to create an event listener to trigger the build based on a Gitea webhook.
+
+:::info
+Configuring a Trigger is only supported when the Repo is in the local Gitea.
+:::
+
 
 ### Buildpacks
 
 1. Add the URL of the Git repository that contains the application source code
 2. (optional) Add the path. This is a subpath within the repo where the source to build is located
 3. (optional) Change the revsion. This can be a commit, a tag, or a branch
+4. (optional) Select to create an event listener to trigger the build based on a Gitea webhook.
+
+:::info
+Configuring a Trigger is only supported when the Repo is in the local Gitea.
+:::
 
 ### Build status
 
-To see the status of a build:
+To see the status of the build, click on the `PipelineRun` link of the build in the list of builds. If a trigger is configured, the link will show all PipelineRuns.
 
-- Start/open a shell in the console
+### Restart a build
+
+To restart a build:
+
+- Start a shell in the console
 - run the following command:
 
 ```

docs/for-devs/console/services.md

@@ -12,6 +12,16 @@ A service in Otomi is a self-service feature for:
 - Private (in-cluster) exposure of ClusterIP services
 - Configure network policies
 
+## Services `(team <team-name>)`
+
+All known Services of the team are listed here. Services can be sorted based on:
+
+| Property     | Description                                            |
+| ------------ | ------------------------------------------------------ |
+| Service Name | The name of the service                                |
+| Ingress class     | The ingress class configured. This is the ingress controller that exposes the service              |
+| URL        | The URL of the service if the service is configured for external exposure |
+
 ## Create a Service
 
 1. Enter a name for the service. The name will be used to generate hostname if `Use suggested domain` is chosen (see below). When configuring ingress for an existing (pre-deployed) service, make sure the name provided here matches the name of the CusterIP service
@@ -23,15 +33,15 @@ After providing a name and a port number, you can now configure ingress.
 Exposure controls wether internet exposure should be enabled or not. Three options exist:
 
 - `Private`: choose to expose services in-cluster
-- `Public`: choose to expose services publicly
+- `Public`: choose to expose services on a private or public load balancer
 
 ### Private
 
 Choose private to expose the service in-cluster and configure in-cluster [ingress network policies](#ingress-traffic-inside-the-cluster)
 
-### Public
+### External
 
-Use Public to expose a service with a domain name and a certificate on an external network (using an external load balancer)
+Use External to expose a service with a domain name and a certificate on an external network (using an external load balancer).
 
 A URL will have a hostname that consists of `$HOST_NAME.$DNS_ZONE`. Options are described below.
 
@@ -50,7 +60,9 @@ A URL will have a hostname that consists of `$HOST_NAME.$DNS_ZONE`. Options are
 | HTTP Response Headers            | HTTP Response headers that will be set on the exposed service                                                             |
 
 
-## Configure CNAME (available from v0.26)
+## Use CNAME
+
+Select `Use CNAME` when the URL of the service is used as a value in a CNAME.
 ### With TLS Termination at the NGINX Controller
 
 Follow the steps below to set up a CNAME when the TLS termination happens on the NGINX controller.

docs/for-devs/console/workloads.md

@@ -22,6 +22,16 @@ Ask you platform administrator to activate ArgoCD to be able to use this feature
 Ask you platform administrator to activate Knative to be able to create Function as a Service workloads.
 :::
 
+## Workloads (all)
+
+All known Workloads of the team are listed here.
+
+| Property      | Description                                            |
+| ------------- | ------------------------------------------------------ |
+| Workload Name | The name of the workload                               |
+| Type | The type of the workload (deployment/ksvc/custom)               |
+| Argocd | Link to the ArgoCD application in the ArgoCD UI               |
+
 
 ## Create a Workload
 
@@ -69,6 +79,23 @@ After a few minutes, Otomi will have created all the needed ArgoCD resources to
 
 The values of a workload can be changed at any time. Changes will automatically be deployed.
 
+#### (optional) Configure Auto Image Updater
+
+Workloads with a BYO Helm chart can be configured with the Auto Image Updater. The Auto Image Updater will (based on the update strategy) update the deployed image.
+
+:::info
+Using the auto image updater is only supported when the Helm chart is in a local Gitea repository on the platform, and the image is stored in the local Harbor on the platform.
+:::
+
+1. If the URL for the chart is a local Gitea repo, the option to enable the Auto Image updater will become active. Select `Enabled`
+2. Fill in a Build name (a Build created in Otomi) or the name of an existing image in harbor (without `*/team-<name>/`)
+3. Select the Update strategy. Choose between:
+
+- Latest: Update to the most recently built image.
+- Digest: Update to the most recent pushed version of a given tag. Requires to provide a `tag`.
+- Semver: Update based on semantic versions. Example: `1.0` would allow the image to be updated to any patch version within the 1.0 minor release.
+
+
 ### Basic values
 
 | Title               | Value               | Description                                            |

docs/for-devs/get-started/lab-17.md

@@ -1,7 +1,7 @@
 ---
 slug: lab-17
 title: Scan your running containers for vulnerabilities
-sidebar_label: Scan container
+sidebar_label: Scan running containers
 ---
 
 :::info

docs/for-devs/get-started/lab-4.md

@@ -1,7 +1,7 @@
 ---
 slug: lab-4
 title: Create a CI pipeline
-sidebar_label: Create CI pipeline
+sidebar_label: Create a custom CI pipeline
 ---
 
 Kubernetes is a container orchestrator, so we need to create container images that we can deploy. Next to providing a Git service. Otomi also has a complete CI solution called Drone integrated. You can use Drone to create and run CI pipelines to build images and push them to your private image registry (Harbor).

docs/for-ops/console/backups.md

@@ -8,7 +8,9 @@ sidebar_label: Backups
 To enable this feature, first make sure [Velero](../../apps/velero.md) is activated.
 :::
 
-All known Builds on the platform are listed here. Builds can be sorted based on:
+When Velero is activated on the platform level, platform admins can create backups of Persistent Volumes (PVs) in Team namespaces using Otomi Console. When creating backups using Otomi Console, a Velero `schedule` resource is created that will create the backup at a specified time, defined by a Cron expression.
+
+All known Backups on the platform are listed here. Builds can be sorted based on:
 
 | Property      | Description                                            |
 | ------------- | ------------------------------------------------------ |
@@ -19,7 +21,7 @@ All known Builds on the platform are listed here. Builds can be sorted based on:
 ## Create a backup
 
 :::note
-Backup can only be created by platform administrators
+Backups of Team PVs can only be created by platform administrators
 :::
 
 1. Select the Team name in the top bar to set the context to the namespace that contains the PV to backup

docs/for-ops/console/builds.md

@@ -13,6 +13,10 @@ All known Builds on the platform are listed here. Builds can be sorted based on:
 | Property      | Description                                            |
 | ------------- | ------------------------------------------------------ |
 | Build         | The name of the build                                  |
+| Type          | Type of the build. Buildpacks or Docker                |
+| Trigger       | Is trigger configured for the build                    |
+| Tekton        | Link to the PipelineRun of the build in Tekton dashboard |
+| Harbor        | Link to the image in Harbor                            |
 | Team          | The name of the Team responsible for the build         |
 
 A platform admin can also create builds. Make sure to select the correct context (team-name) in the top bar. See [here](/docs/for-devs/console/builds) for more information about creating builds.

docs/for-ops/console/services.md

@@ -11,9 +11,8 @@ All known Services on the platform are listed here. Services can be sorted based
 | Property     | Description                                            |
 | ------------ | ------------------------------------------------------ |
 | Service Name | The name of the service                                |
-| Ingress type     | Configured ingress type (`public` / `cluster`)               |
-| Service type         | The service type (`svcPredeployed` / `ksvcPredeployed` / `ksvc`) |
-| Host         | The hostname of the service |
+| Ingress class     | The ingress class configured. This is the ingress controller that exposes the service              |
+| URL        | The URL of the service if the service is configured for external exposure |
 | Team         | The team that owns the service                         |
 
 Follow the instructions [here](../../for-devs/console/services.md) to create a service.

docs/for-ops/console/workloads.md

@@ -13,6 +13,8 @@ All known Workloads on the platform are listed here. Workloads can be sorted bas
 | Property      | Description                                            |
 | ------------- | ------------------------------------------------------ |
 | Workload Name | The name of the workload                               |
+| Type | The type of the workload (deployment/ksvc/custom)               |
+| Argocd | Link to the ArgoCD application in the ArgoCD UI               |
 | Team Name     | The name of the Team responsible for the workload      |
 
 A platform admin can also create Workloads. Make sure to select the correct context (team-name) in the top bar. See [here](/docs/for-devs/console/workloads) for more information about creating builds.

docs/for-ops/how-to/install-with-dns.md

@@ -4,7 +4,7 @@ title: Install Otomi with DNS
 sidebar_label: Install with DNS
 ---
 
-## Install Otomi with DNS using AWS Route53
+## Route53
 
 Follow the following steps to install Otomi with DNS using AWS Route53.
 
@@ -115,4 +115,5 @@ apps:
 helm repo add otomi https://otomi.io/otomi-core
 helm repo update
 helm install -f values.yaml otomi otomi/otomi
-```
+```
+

docs/get-started/installation.md

@@ -18,7 +18,7 @@ See [helm repo](https://helm.sh/docs/helm/helm_repo/) for command documentation.
 #### Minimal configuration
 
 :::info
-As of version [0.26.0](https://github.com/redkubes/otomi-core/releases/tag/v0.21.0) Otomi supports Kubernetes versions `1.24`,`1.25` and `1.26`.
+As of version [0.26.0](https://github.com/redkubes/otomi-core/releases/tag/v0.21.0) Otomi supports Kubernetes versions `1.25`,`1.26` and `1.27`.
 :::
 
 :::info

docs/get-started/prerequisites.md

@@ -55,8 +55,9 @@ When using Minikube, only Otomi Core apps can be used! Activating more apps will
 
 Otomi currently supports the following Kubernetes versions:
 
-- `1.24`
 - `1.25`
+- `1.26`
+- `1.27`
 
 ### Minimal compute resource requirements
 

src/data/apps.js

@@ -1,4 +1,28 @@
 export default [
+  {
+    href: "https://github.com/open-telemetry/opentelemetry-operator",
+    src: "otel-logo.svg",
+    name: "OpenTelemetry",
+    desc: "Instrument, generate, collect, and export telemetry data",
+  },
+  {
+    href: "https://github.com/GoogleContainerTools/kaniko",
+    src: "kaniko-logo.png",
+    name: "Kaniko",
+    desc: "Build images from Dockerfile",
+  },
+  {
+    href: "https://github.com/grafana/tempo",
+    src: "tempo-logo.svg",
+    name: "Tempo",
+    desc: "Distributed tracing backend",
+  },
+  {
+    href: "https://github.com/cloudnative-pg/cloudnative-pg",
+    src: "cnpg-logo.svg",
+    name: "Cloudnative-pg",
+    desc: "Operator to manage PostgreSQL workloads",
+  },
   {
     href: "https://argo-cd.readthedocs.io/",
     src: "argo-cd.svg",

src/pages/index.tsx

@@ -59,7 +59,7 @@ function Home() {
         </div>
         <div className={clsx(styles.announcement, styles.announcementBanner)}>
           <div className={styles.announcementInner}>
-            <h1>DEMO</h1> <h4>BUILD, DEPLOY and EXPOSE apps on Kubernetes with OTOMI</h4>
+            <h1>DEMO</h1> <h4>CODE, BUILD and RUN apps on Kubernetes with OTOMI</h4>
           </div>
         </div>
         <div
@@ -91,7 +91,7 @@ function Home() {
         <div className={clsx(styles.announcement, styles.announcementBanner)}>
           <div className={styles.announcementInner}>
           <div className={styles.announcementInner}>
-            <h1>INTEGRATED TOOLS</h1> <h4>Create your own suite of PRE-CONFIGURED, INTEGRATED and AUTOMATED tools</h4>
+            <h1>INTEGRATED APPLICATIONS</h1> <h4>Compose your platform by activating the required Kubernetes applications </h4>
           </div>
           </div>
         </div>