docs: update for v0.4

README.md

@@ -1,3 +1,8 @@
+> [!WARNING]
+> This project is still in a pre-release state, minor versions will introduce breaking changes until 1.0
+> 
+> You should only use releases, as the main branch can be broken.
+
 # burrito <!-- omit in toc -->
 
 [![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)

docs/getting-started.md

@@ -1,24 +1,28 @@
 # Getting started
 
+## Pre-requisites
+
+- A kubernetes cluster
+- A bucket in a cloud provider (AWS, GCP, Azure)
+- cert-manager installed in your cluster (Will only be used for internal communications using a private CA)
+
 ## Requirements
 
-- Installed [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) command-line tool.
+- Installed [helm](https://helm.sh/docs/intro/install/) command-line tool.
 - Have a [kubeconfig](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) file (default location is `~/.kube/config`).
 
 ## 1. Install burrito
 
 ```bash
-kubectl create namespace burrito
-kubectl apply -n burrito -f https://raw.githubusercontent.com/padok-team/burrito/main/manifests/install.yaml
+helm repo add burrito oci://ghcr.io/padok-team/charts
+helm repo update
+helm install burrito burrito/burrito -n burrito-system
 ```
 
-This will create a new namespace, `burrito`, where burrito services will live.
+This will create a new namespace, `burrito-system`, where burrito services will live.
 
 !!! warning
-    The installation manifests include `ClusterRoleBinding` resources that reference `burrito` namespace. If you are installing burrito into a different namespace then make sure to update the namespace reference.
-
-!!! info
-    You might be interested by our [Helm chart](./operator-manual/install/with-helm.md), that provides more control over burrito's configuration as well as a [multi-tenant architecture](./operator-manual/multi-tenant-architecture.md).
+    The installation manifests include `ClusterRoleBinding` resources that reference `burrito-system` namespace. If you are installing burrito into a different namespace then make sure to update the namespace reference.
 
 ## 2. Create a connection to a private repository
 

docs/operator-manual/architecture.md

@@ -32,9 +32,9 @@ It is responsible for running the `terraform plan` and `terraform apply` command
 
 It also generates [`Leases`](https://kubernetes.io/docs/concepts/architecture/leases/) to make sure no concurrent terraform commands will be launched on the same layer at the same time.
 
-### The Redis instance
+### The Datastore instance
 
-The Redis instance is used to store the binary generated by `terraform plan` before running the `apply`. We also store information about the `plan`/`apply` output to print it in the resources' statuses
+The Datastore instance of Burrito is a http proxy that provides download/upload capabilities to the runners. It is used to store the Terraform plan files generated by the runners and to store the associated logs.
 
 ## Implementation
 

docs/operator-manual/datastore.md

@@ -0,0 +1,34 @@
+# Datastore
+
+## Configuration
+
+The Datastore storage backend can be configured using the following yaml configuration :
+
+```yaml
+config:
+  burrito:
+    datastore:
+      storage:
+        s3:
+          bucket: XXX
+        gcs:
+          bucket: XXX
+        azure:
+          storageAccount: XXX
+          container: XXX
+```
+
+!!! info
+    Only one storage backend can be configured at a time.
+
+## Authentication
+
+The different cloud provider implementations rely on the default credentials chain of the cloud provider SDKs.
+
+## Authorization
+
+The Datastore relies on TokenReview and mounted volumes for authorization. We rely on a custom audience for the TokenReview to ensure that the token can only be used for the Datastore.
+
+## Object expiration
+
+For now the datastore doesn't delete any object it puts into the storage backend. This is a feature that will be implemented in the future.

docs/user-guide/additionnal-trigger-path.md

@@ -1,6 +1,6 @@
 # Additionnal Trigger Paths
 
-By default, when you creating a layer, you must specify a repository and a path. This path is used to trigger the layer changes which means that when a change occurs in this path, the layer will be plan / apply accordingly.
+By default, when you are creating a layer, you must specify a repository and a path. This path is used to trigger the layer changes which means that when a change occurs in this path, the layer will be plan / apply accordingly.
 
 Sometimes, you need to trigger changes on a layer where the changes are not in the same path (e.g. update made on an internal terraform module hosted on the same repository).
 

docs/user-guide/terraform-version.md

@@ -1,5 +1,7 @@
 # Choose a terraform/terragrunt version
 
+For now, Burrito doesn't auto-detect the terraform or terragrunt version used in your repository. You have to specify it in the `TerraformRepository` or `TerraformLayer` resource.
+
 ## Choose terraform version
 
 Both `TerraformRepository` and `TerraformLayer` expose a `spec.terrafrom.version` map field.