[FLI-916] Other formats for declarative state

[Mark Phelps]

Problem

We currently support declarative flag state in YAML format: https://www.flipt.io/docs/configuration/storage#defining-flag-state

YAML is ok, but I'm wondering if it makes sense to support other formats for defining flag state. These other formats may allow for us to do more concrete validation of data, or support things such as references and functions

Ideal Solution

One of the first formats I've thought we could support is HCL from Hashicorp.

I've started working on a proof of concept parser that would allow us to define flag state in HCL and then turn that into native objects that Flipt can work with (ie for import/export or serving evaluation if using a declarative backend).

Heres what it might look like:

namespace "example" {
	name = "Example"
	description = "An example namespace"
}

flag "feature" {
	namespace = namespace.example
	name = "feature"
	type = "variant"
	enabled = true
	description = "A feature flag"
	
	variants = [
		{
			key = "enabled"
			name = "enabled"
			description = "The feature is enabled"
		},
		{
			key = "disabled"
			name = "disabled"
			description = "The feature is disabled"
		}
	]

	rules = {
		{
			segment = segment.example
			variant = "enabled"
		},
		{
			segment = segment.example
			distributions = {
				{
					rollout = 50
					variant = "enabled"
				},
				{
					rollout = 50
					variant = "disabled"
				}
			}
		}
	}
}

segment "example" {
	namespace = namespace.example
	name = "example"
	description = "An example segment"
	match_type = "all"

	constraints = {
		{
			type = "string"
			property = "email"
			operator = "contains"
			value = ["@example.com"]
		}
	}
}

Before I go too far, I wanted to open this up for feedback to see:

1. If anyone would find this useful/interesting to support other formats for flag state in Flipt
2. If HCL is the 'right' choice, as there are other options available as well, such as PKL from Apple

Search

• I searched for other open and closed issues before opening this

Additional Context

No response

_FLI-916

[Alexandre Picard-Lemieux]

Hello 👋,

I like the idea of it. I think you will gain more by doing one of the following.

1. Pulumi (People can use the language of their choice and can used their common tools)
2. Kubernetes Operator.

The last one can be used by either pulumi, HCL/terraform, CUE, etc.