Combinatorial Configuration and Cue

[cueckoo]

Originally opened by @verdverm in cuelang/cue#411

When managing systems in the wild, especially for operations which require deploying to multiple clouds (and emerging trends in enterprise OSS buying preferences), microservices, helm charts...

What we see is a combinatorial explosion of configuration options. For example:

• env: { local, [...branch], dev, stage, prod }
• cloud: { gcp, aws, azure, .... }
• runtime: { k8s, vm, serverless, ... }
• componnts: nCm inclusion choice
• sizing: sm, md. lg (providing t-shirt sizing simplicity to users / devs)
• this list could go on and on...

Many of us are coming to Cue to see if there is a solution to this largely unsolved ops problem. Discussion on slack, and some personal experimentation, have lead to three possible solution so far:

1. Use a _<tag>.cue convention
2. Use lookup tables for each dimension
3. Use attributes

We are still very much in the experimentation phase and there are a lot of open questions.

One that stands out w.r.t. this discussion is:

should this even be Cue's problem to solve?

Option 1 requires Cue maintainers to write core code to handle this

Option 2 & 3 do not have this requirement, and both are possible within the same cue code. 2 can be written in pure Cue while 3 can only be done in tools built on the API.

My experiments are here (I'm currently working on the attrs version)

• Option 2 (lookup tables): https://github.com/hofstadter-io/jumpfiles
• Option 3 (attrs based): https://github.com/hofstadter-io/hof (this one is using attributes in a lot of places for a lot of things, I'll come back and add more specifics as I push code this weekend)

[cueckoo]

Original reply by @tkellen in cuelang/cue#411 (comment)

Just dropping a note here to say how thankful I am to see this conversation happening. As a longtime user of kustomize searching for a better solution, this project appears to be a oasis in a desert full of failed attempts to solve this issue in a novel way.

[cueckoo]

Original reply by @mpvl in cuelang/cue#411 (comment)

I think the equivalent of Go "build tags" would be quite useful. So far they have been left out, as the --inject mechanism solves the same and is a more general solution overall. However, the latter does force another level of indentation around blocks of files to include (if env == "prod" { ... }).

Build tags would take the form of, say, having file-level attributes:

@build(prod)

package foo

a: b

module bike shedding of names and other details, where this file is only included in evaluation if a tag prod is specified on the command line, so, say, cue export -t prod (here it piggybacks on the existing --inject/-t flag). By convention, files with such a build tag could be named filename_prod.cue.

I think that with this mechanism, CUE will have all the necessary tools for slicing and dicing configurations. The only drawback would be introducing another mechanism to learn that is to some extent redundant. After all, the above can be written as:

package foo

#env: string @tag(env,short=prod|stage|test)

if #env == "prod" {
    a: b
}

[cueckoo]

Original reply by @seh in cuelang/cue#411 (comment)

I think that with this mechanism, CUE will have all the necessary tools for slicing and dicing configurations. The only drawback would be introducing another mechanism to learn that is to some extent redundant. After all, the above can be written as:

True, though it will probably involve at least one extra file: one for the "#env" definition, separate from the files named with the discriminating suffix.

Past that, though, it would help to work through an example that shows more than one such "axis" or "dimension" being customized. To go back to a common example these days, consider fitness environment (your "test", "stage", and "prod") and cloud provider ("aws", "azure", and "gcp" to start). Some things are common per fitness environment. Some things are common per cloud provider. Some things need to be specified where they intersect (e.g. "test" in "aws").

Does this work with more dimensions? Where do the contributing files have to live, thinking about instances of packages?

[cueckoo]

Original reply by @verdverm in cuelang/cue#411 (comment)

With the _<tag>.cue like file extensions...

I'm ok with it, so long as when writing tooling, I don't have to inspect filenames and look for these. This seems like something that would be handled by Cue internally and provided as a field on the instance somewhere.

The idea for this is that we could have configuration that is selectively included during execution. Does this mean it becomes normal to have conflicting values, such that you cannot load the entire module / instance, and can only load successfully when you supply tags or build args?

I've generallty come to avoid the differences between go / cue mods

• only one package per folder
• only one folder per package

So I'm not using the ability to have multiple / spread packages because it feels harder to grok the configuration (thinking about Cue philosophy here). Could this make things generally more difficult to understand? Will it create variety in style that makes reading other's code difficult? (one of the nice things about GO is that everyone's code looks the same)

Thoughts?

[cueckoo]

Original reply by @myitcv in cuelang/cue#411 (comment)

I'm ok with it, so long as when writing tooling, I don't have to inspect filenames and look for these.

I don't think that's avoidable. In the case of GOOS and GOARCH, because they are well-known, well-defined sets, they can be made into a special case for file name suffixes.

For everything else there is the go/build or the new, higher-level go/packages which help determine which files are part of the "build".

Noting golang/go#25348 in which there is a new design in the works.

[cueckoo]

Original reply by @verdverm in cuelang/cue#411 (comment)

I'd be fine with (and would expect if accepted) packages / config options for handling this, that likely the CUe internal systems would make use of for CLI commands (in example).

What I'm saying is that it would be burdensome to put that low-level determination on tool authors (where low-level would be inspecting files and filenames to make this determination, whether golang os.Filetype.Name() or cue.Instance.Files)

What I'm hearing is that we are likely on the same page about "if this is accepted, there will be helpers made available"

So I don't have any strong opinions other than that this can also be expressed with the attribute system. (and possibly, file extensions are sugar for an equivalent file-level attribute?)