Skip to content

crossplane.io/external-name takes precedence over krm.kcl.dev/composition-resource-name in composition resource names #217

Open
@irizzant

Description

@irizzant

What happened?

I have a Composition where a MR is created with Observe managementPolicies and I set crossplane.io/external-name annotation to the name of the observed resource:

{
            apiVersion = "repo.github.upbound.io/v1alpha1"
            kind = "Repository"
            metadata = _metadata("repository", "app") | {
                labels = _appRepositoryLabels
                annotations = {
                    "crossplane.io/external-name" = _projectNamespaceId
                }
            }
            spec = _defaults | {
                managementPolicies = ["Observe"]
                ....            }
        }

The _metadata lambda sets both metadata.name and krm.kcl.dev/composition-resource-name using different values:

_metadata = lambda kind: str, suffix: str -> any {
    {
        annotations = {
            "krm.kcl.dev/composition-resource-name" = id + "-" + kind + "-" + suffix
        }
        if suffix == "":
            name = parameters.project + "-" + id 
        else:
            name = parameters.project + "-" + id + "-" + suffix
    }
}

When I read the option("params").ocds map this MR is stored with a key equal to metadata.name value, even though I would have expected it to use the krm.kcl.dev/composition-resource-name instead.

It looks like the metadata.name is taking precedence over krm.kcl.dev/composition-resource-name, maybe it's related to the changes introduced with #81 and in particular https://github.com/ytsarev/function-kcl/blob/9d72b1c4fab4e1a5ec12f7425fa3464549024ed7/pkg/resource/res.go#L476-L481?

How can we reproduce it?

What environment did it happen in?

Function version: 0.10.10

Kubernetes version 1.32
Kubernetes distro: kind
OS: Ubuntu 24.04.1 LTS

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions