Approach to manage common configurations in CUE

[cueckoo]

Originally opened by @selfuryon in cuelang/cue#910

Hello! I have a question about how do you manage common configurations in cue?
As example, I have this structure:

.
├── apps
│   └── metallb
│       ├── configmap.cue
│       ├── kube.cue
│       └── metallb-v.0.9.6.cue
├── env1
│   └── main.cue
├── env2
│   └── main.cue
└── env3
    └── main.cue

I have imported mettalb yaml to cue and I want to add metallb in all environments. Metallb consist of many items like serviceAccounts, daemonSets so I want to manage it only from one place (don't put it in each environment), but it also need personal configmap for each envs.
I find two approaches:
1st: import whole configuration:

package kube

import (
    "encoding/yaml"
    metallb "test.io/apps/metallb:kube"
)

metallb

configMap: config: {
    data: {
        config: yaml.Marshal(mlb_config)
        let mlb_config = {
            "address-pools": [{
                name:     "public"
                protocol: "layer2"
                addresses: ["10.1.130.101-10.1.130.110"]
            }]
        }
    }
}

2nd: import all resources personally:

package kube

import (
    "encoding/yaml"
    metallb "test.io/apps/metallb:kube"
)

configMap: config: {
    data: {
        config: yaml.Marshal(mlb_config)
        let mlb_config = {
            "address-pools": [{
                name:     "public"
                protocol: "layer2"
                addresses: ["10.1.130.101-10.1.130.110"]
            }]
        }
    }
}

serviceAccount: controller: metallb.serviceAccount.controller
serviceAccount: speaker:    metallb.serviceAccount.speaker
...

The second approach is a bit weird, but I don't know the first is ok and someone uses this approach or not because it's a bit hacky too

[cueckoo]

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

@selfuryon apologies for the delay in replying to your question.

Either will work, the embedding in approach 1 is "cleaner" in my opinion.

If metallb is indeed common to all sub-instances env1, env2 and env3, another approach is to move the definition of metallb to the parent directory. Here's a rough example:

exec cue eval ./env1
exec cue eval ./env2
exec cue eval ./env3

-- cue.mod/module.cue --
module: "metallb.com"
-- env1/env1.cue --
package kube

config: {
	env: "env1"
}
-- env2/env2.cue --
package kube

config: {
	env: "env2"
}
-- env3/env3.cue --
package kube

config: {
	env: "env3"
}
-- metallb.cue --
package kube

config: {
	name: "metallb"
}

Gives the output:

> exec cue eval ./env1
[stdout]
config: {
    name: "metallb"
    env:  "env1"
}
> exec cue eval ./env2
[stdout]
config: {
    name: "metallb"
    env:  "env2"
}
> exec cue eval ./env3
[stdout]
config: {
    name: "metallb"
    env:  "env3"
}

This obviates the need to import metallb, because CUE combines CUE files from parent directories that belong to the same package, which has exactly the same effect as the embedding in your first example.