[FLI-911] Remote config

[Mark Phelps]

Problem

If you have multiple instances of Flipt (for HA, or any other reason), currently you have to copy the config.yml file between instances to have them configured the same.

Ideal Solution

It could be nice if we allowed specifying config from a remote, such as Git or Cloud Bucket / Object Store.

We already have the code in place to read from these remote sources, so I don't think it would be a huge lift to support this.

This would allow users / operators to share config easily between instances.

Search

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

Additional Context

No response

_FLI-911

[Alexandre Picard-Lemieux]

Remote storage would be my first choice

[Mark Phelps]

Remote storage would be my first choice

So reading from S3/etc?

[Alexandre Picard-Lemieux]

Yes, S3 is what we are using for a lot of our stuff

[Mark Phelps]

Now we just need to figure out how to bootstrap it. Like what makes sense for how to tell Flipt where to go (and how to authenticate) at startup to read the config file from the remote storage.

Maybe a paired down config.yml that points to the bucket / object store like we do for flag state: https://www.flipt.io/docs/configuration/storage#amazon-s3 ?

something like:

config:
  remote:
    type: object
    object:
      type: s3
      s3:
        region: us-east-1
        bucket: flipt_config
        # optional: bucket prefix for locating flag state files
        prefix: production
        # optional: for non-AWS hosted S3
        endpoint: http://localhost:9009

?

Then we would also need to decide if you could override any of the remote config properties by setting them in the local config too. Wdyt?

[Mark Phelps]

@erka had a good idea that instead of specifying where to pull the config in the config itself, we use CLI flag like:

flipt --config s3://my-bucket/flipt/config.yml?region=us-west-1&endpoint=my.minio.local:8080

we'd have to change the --config flag to look for protocols such as s3:// before trying to parse the argument as a file (the current behavior). alternatively we could introduce a new flag like --remote or --remote-config