Update rendered RFCs (#321)

Co-authored-by: taylorbot <[email protected]>

Author: github-actions[bot]

content/docs/rfcs/_index.md

@@ -16,6 +16,7 @@ Want to write a new, technical RFC? Please follow the [RFC and decision making p
 | Created (newest first) | Title | State |
 | ---------------------- | ----- | ----- |
 | 2025-02-04 | <span>[Deploy observability silences using GitOps](./silences-gitops)</span><br><br><span style="opacity: 0.7">Deploy observability silences using GitOps</span> | <span style="color: darkorange">review</span> |
+| 2024-09-26 | <span>[App prefix](./app-prefix)</span><br><br><span style="opacity: 0.7">Decide whether the apps in CAPI cluster should have or not a prefix, and if we need to enforce it.</span> | <span style="color: darkorange">review</span> |
 | 2024-05-22 | <span>[Structured way to propose, discuss, and formalize technical decisions within an organization](./technical-decision-making-process)</span><br><br><span style="opacity: 0.7">This contains the process for proposing, discussing, and formalizing technical decisions. It also introduces the RFC structure.</span> | <span style="color: darkgreen; font-weight: bold">approved</span> |
 | 2024-02-19 | <span>[Revamp our docs](./platform-docs-migration)</span><br><br><span style="opacity: 0.7">Revamp our docs to describe the Dev Platform product, considering the new Cluster API (CAPI) architecture. Temporarily move vintage to a subpath and create the new content in the top level. The docs entry point can still point to the old till renovation is over.</span> | <span style="color: darkgreen; font-weight: bold">approved</span> |
 | 2023-10-26 | <span>[Importing EKS/AKS/GKE clusters to CAPI using crossplane](./crossplane-capi-import)</span><br><br><span style="opacity: 0.7">In order for Giant Swarm to import/adopt customer clusters on bring-your-own infrastructure, use Crossplane `ObserveOnly` functionality for resources to discover existing infrastructure of customers without managing it. Use `clusters.x-k8s.io/managed-by: crossplane` annotation to prevent CAPI from reconciling clusters. Do not rely on "paused" objects.</span> | <span style="color: darkgreen; font-weight: bold">approved</span> |

content/docs/rfcs/app-prefix/_index.md

@@ -0,0 +1,48 @@
+---
+# DO NOT EDIT! Auto-generated by `handbook/scripts/aggregate-rfcs.py` from https://github.com/giantswarm/rfc/tree/main/app-prefix - changes to this file will be overwritten!
+hide_summary: true
+title: App prefix
+toc_hide: true
+---
+
+| Created | State | Summary |
+|-|-|-|
+| 2024-09-26 | <span style="color: darkorange">review</span> | Decide whether the apps in CAPI cluster should have or not a prefix, and if we need to enforce it. |
+
+## Intro
+
+When we moved to Cluster API, we decided that all resources would live the organization namespace. That decision means apps, including the cluster app, from different clusters coexist in the same namespace. It also means, it forces us to name the apps differently to avoid conflicts. [More information in the following discussion](https://github.com/giantswarm/workload-clusters-fleet/pull/802#issuecomment-1946218047)
+
+## Scope
+
+This affects `kubectl gs` since we have a mix of functionality. In `gitops` subcommand we append the cluster id as a prefix on the output but in `template` subcommand the user needs too add explicitly the `--app-name` with the prefix on it.
+
+When users use the GitOps template, we advocate relying on the `namePrefix` variable to prefix the apps and config maps automatically.
+
+Lately, happa has also prefixed the apps automatically.
+
+We don't validate or mutate the app name via the management cluster API.
+
+## Solution
+
+We decided to not enforce the cluster prefix but encourage customers to use it as good practice.
+
+### API enforcement
+
+- The app admission controller will validate the name of the apps when deploying to the organization namespace to avoid collisions and conflicts that can unexpectedly affect customers.
+
+- The app admission controller will warn the user when creating an application with no prefix or a prefix that does not match any existing cluster.
+
+We unify the behavior across all the tools and commands. The kubectl's `gitops` commands will no longer auto prefix the apps in a newer version.
+
+## Alternatives
+
+### Do not enforce
+
+Leave the customer the freedom to name the apps as they want. This will impact neglected customers who forgot to prefix their apps, potentially unintentionally uninstalling apps or moving to clusters. We will let them choose what type of convention they take.
+
+We could potentially hide it from the customer. This would make the user experience more friendly, but it would also make debugging harder. Our `kubectl-gs` command could get the app without the need for a prefix, or the portal could show the app without containing the prefix.
+
+## References
+
+- [Discussion](https://github.com/giantswarm/workload-clusters-fleet/pull/802)