Surprising effect of bulk field templates

[mxey]

I am trying to have Kubernetes objects for a component that can be instantiated multiple times and then emit all the objects to (eventually) pass them to kubectl.

This is the CUE code I have, simplified to a minimal reproduction:

Component: {
	class: string

	objects: {
		ConfigMap: "\(class)-component": {
			kind:       "ConfigMap"
			apiVersion: "v1"
		}
	}

	objects: [string]: [string]: metadata: labels: {
		"class": class
	}
}

a: Component & {class: "a"}
b: Component & {class: "b"}

objects: {
	a.objects
	b.objects
}

When I run CUE, I get conflicts that I find surprising:

$ cue export example.cue -e 'objects'
objects.ConfigMap."a-component".metadata.labels.class: conflicting values "b" and "a":
    ./example.cue:11:21
    ./example.cue:11:31
    ./example.cue:12:12
    ./example.cue:16:24
    ./example.cue:17:24
    ./example.cue:20:2
    ./example.cue:21:2
objects.ConfigMap."b-component".metadata.labels.class: conflicting values "b" and "a":
    ./example.cue:11:21
    ./example.cue:11:31
    ./example.cue:12:12
    ./example.cue:16:24
    ./example.cue:17:24
    ./example.cue:20:2
    ./example.cue:21:2

It seems like this block is applied by both components to both components:

	objects: [string]: [string]: metadata: labels: {
		"class": class
	}

In this example, there is only a single ConfigMap, but in reality there are multiple ones. I want to use this block to set common labels for all objects of this component. I would like to keep the single objects struct with all of them so I can avoid conflicting objects.

[mxey]

This approach seems to work, but seems rather convoluted in comparison:

	for kind, objs in objects {
		for name, obj in objs {
			objects: "\(kind)": "\(name)": metadata: labels: "class": class
		}
	}

[seh]

Instead of embedding a.objects and b.objects into the top-level objects field's value, did you intend to concatenate them?

Oh, I see, you're embedding two trees that have distinct branches partway down.

[myitcv]

AFAICT this is actually working as intended. The reason is that the Component.objects pattern constraint [string]: [string]: metadata: labels applies to existing fields (somewhat related I note the observations in #1024, but this does not affect the analysis of this case). Hence it applies to Component.objects.ConfigMap, hence we see the following (using 0070bb10):

exec cue eval

-- x.cue --
package x

Component: {
	class: string

	objects: {
		ConfigMap: "\(class)-component": {
			kind:       "ConfigMap"
			apiVersion: "v1"
		}
	}

	objects: [string]: [string]: metadata: labels: {
		"class": class
	}
}

a: Component & {class: "a"}
b: Component & {class: "b"}

gives:

...
a: {
    class: "a"
    objects: {
        ConfigMap: {
            "a-component": {
                kind: "ConfigMap"
                metadata: {
                    labels: {
                        class: "a"
                    }
                }
                apiVersion: "v1"
            }
        }
    }
}
...

Therefore when a.objects and b.objects are both embedded into another object (as shown in the description), the constraints conflict. Because the constraint from a.objects is:

	[string]: [string]: metadata: labels: {
		"class": "a"
	}

which b.objects does not satisfy, and vice-versa.

[cueckoo]

This discussion has been migrated to cue-lang/cue#893.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.