GitLab is in the process of streamlining our delivery process, including pushing the ownership of chart definitions left towards teams, and providing guardrails (through OPA policies, documentation, etc) to ensure that we maintain consistency throughout our charts even as we move to allow a wider audience of engineers at the company to author these charts. Some of this has been described in [The Component Ownership Model Process](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/component-ownership-model/). This process will lead to features being released into our Helm charts early on, allowing these charts to used for early experimentation on GitLab.com and Cells. Additionally, with the rise of AI features, some customers have demanded early access to features which may not yet be GA. This leads to a situation where it becomes difficult for customers to know which features in our charts are Experimental, Beta or Stable. Additionally, similar to our API, there should be lowered requirements for stability on these pre-GA features, allowing for rapid iteration and experimentation. This issue describes a way of annotation and guarding against accidental use of non-GA features in our charts, unless it is done through a conscious decision by the customer to do so. ## Introducing JSON Schema JSON Schema (https://json-schema.org/) is a widely adopted technology for ensuring that a data structure adheres to a set of validations. This data structure is often a YAML or JSON document, but it can be used for other purposes too. JSON Schema allows has an expressive vocabulary, allowing for complex validations to be expressed in a declarative manner. JSON Schema is being adopted in various projects at GitLab, and has been used successfully in the GitLab Dedicated group for a number of years to allow for design-by-contract and consistency between Switchboard and the Provisioning control-plane using the Tenant Model schema. Helm also has support for JSON Schema. When a `values.schema.json` exists in the chart, Helm will validate the the users `values.yaml` configuration against this schema. When a schema does not validate, Helm will not apply a change, potentially preventing costly mistakes and downtime for customers due to misconfiguration or a misunderstanding. As a safety mechanism, ideally all GitLab charts should provide a `values.schema.json`. ## JSON Schema and Experimental, Beta and Stable Features How can JSON Schema be used to prevent accidental usage of experimental features by customers. In our charts, we could consistently add an opt-in input value on each chart to allow for experimental or beta features. By default, if this value is omitted, the customer will only be validated to use stable features. For instance, to opt into beta features in the chart, the customer might configure their `values.yaml` as follows: ```yaml # values.yaml features.opt_in=beta ``` In the JSON Schema, this can be used to validate whether any beta or experimental features can be used. For example, if a new component, `wombat` was experimentally added to the chart, but not yet GA, and was enabled using `wombat.enabled`: ```yaml # values.yaml wombat.enabled=true # Helm Fails: JSON Schema Validation Error ``` Then customers would need to opt-into experimental features before setting `wombat.enabled=true`, as follows: ```yaml # values.yaml features.opt_in=experimental wombat.enabled=true ``` This approach would have multiple benefits: 1. Allow us to iterate on design without the need for forward compatibility guarantees on the values for beta and experimental features. 2. Provide customers with a clear guided path to what is stable 3. Prevent the accidental usage of beta or GA features 4. Allow customers to opt-in to beta or experimental features 5. Allow features to be tested on GitLab.com and other SAAS properties without the need to fork or patch the charts (similar to features flags in the application) cc @WarheadsSE