csctl confused on several releases in one OCI repository

[garloff]

/kind bug

What steps did you take and what happened:
Trying to publish an scs2 cluster-stack release

export OCI_REGISTRY=registry.scs.community
export OCI_REPOSITORY=$OCI_REGISTRY/kaas/cluster-stacks
export OCI_USERNAME='robot$REDACTED'
OCI_PASSWORD="REDACTED" \
  csctl create -m stable --publish --remote oci providers/openstack/scs2

gives me

path "providers/openstack/scs2": cluster stack hash: "vwlbjtw3nnhtire1qx7ffo9a8v8qpkditzy2svv4knw"
Error: failed to create create options: failed to get latest release form remote repository: failed to get match release tag "openstack-hosted-control-plane-1-34-v0-sha-0ewkztd" with spec of ClusterStack: failed to get clusterstack object from string "openstack-hosted-control-plane-1-34-v0-sha-0ewkztd": invalid forma

There is no trace of anything hosted-control-plane that I want to publish.
Nevertheless, csctl barfs on it -- probably based on what it finds on the registry, which it looks at to determine the version, I guess ...

[A clear and concise description of what the bug is.]

csctl should not care about openstack-hosted-cotrol-plane when I try to publish openstack-scs2
providers/openstack/scs2/csctl.yaml:

garloff@dev2018(://):/casa/src/SCS/cluster-stacks [1]$ cat providers/openstack/scs2/csctl.yaml
apiVersion: csctl.clusterstack.x-k8s.io/v1alpha1
config:
  clusterStackName: scs2
  kubernetesVersion: v1.33.10
  provider:
    apiVersion: openstack.csctl.clusterstack.x-k8s.io/v1alpha1
    type: openstack

What did you expect to happen:

csctl to determine what version to assign to my openstack-scs-1-33 (v5, I guess) and push it out.

Anything else you would like to add:
This prevents me from publishing openstack-scs2-1-33-v5 (k8s-v1.33.10, SovereignCloudStack/cluster-stacks#260) and openstack-scs2-1-34-v2 (k8s-v1.34.7, SovereignCloudStack/cluster-stacks#261).

Environment:

csctl version:
csctl version: dev
commit: unknown

(this was built from git 800cac6, last commit from Dec 31, 2025)
Side question: Should I open a separate bug on csctl's inability to report its own version?

[janiskemper]

I could imagine that it is a formatting problem, that you need a "." not a "-" in the version string "openstack-hosted-control-plane-1-34-v0-sha-0ewkztd".

So "openstack-hosted-control-plane-1-34-v0-sha.0ewkztd".

That would be a solution to the "invalid format" IMO.

[garloff]

Thanks for your quick response, Janis!

This is how the registry looks like (/kaas/cluster-stacks):

Artifacts	Tags	Size	Vulns	SBOM	Push	Last Pull
sha256:503c9120	openstack-scs2-1-34-v0-git-8271ca4	11.03KiB	Unsupported	Unsupported	4/18/26, 11:33 PM	4/24/26, 12:27 PM
sha256:dce929e2	openstack-scs2-1-33-v0-git-6aff802	11.04KiB	Unsupported	Unsupported	4/18/26, 9:11 PM	4/22/26, 5:53 PM
sha256:5c05e1b2	openstack-scs-1-30-v0-git-13a7539	261.86KiB	Unsupported	Unsupported	4/13/26, 5:18 PM	4/24/26, 12:28 PM
sha256:3f54f243	openstack-scs2-1-34-v0-git-bdddbeb	11.04KiB	Unsupported	Unsupported	2/20/26, 3:29 PM	4/18/26, 11:15 PM
sha256:19750651	openstack-scs2-1-34-v0-git-98555b0	29.45KiB	Unsupported	Unsupported	2/20/26, 12:03 PM	2/20/26, 2:32 PM
sha256:ae5c0568	openstack-hostedcontrolplane-1-34-v0-sha-sjlbc7x	9.27KiB	Unsupported	Unsupported	1/28/26, 4:36 PM	1/29/26, 10:06 AM
sha256:b564e20e	openstack-hostedcontrolplane-1-34-v0-sha-b2sierw	9.26KiB	Unsupported	Unsupported	1/28/26, 4:32 PM	1/28/26, 4:34 PM
sha256:54a01423	openstack-hosted-control-plane-1-34-v0-sha-0ewkztd	9.27KiB	Unsupported	Unsupported	1/28/26, 4:32 PM
sha256:1115d8cf	openstack-hosted-control-plane-1-34-v0-sha-mmppsnn	9.27KiB	Unsupported	Unsupported	1/28/26, 4:17 PM
sha256:8522910d	openstack-scs2-1-34-v1	29.38KiB	Unsupported	Unsupported	12/20/25, 10:47 AM	4/24/26, 12:27 PM

I see nothing that's obviously wrong here ...

[janiskemper]

mmh okay.. I guess @jschoone is maybe better to answer then. I still could imagine it is related, but I think it's not csctl but rather the files given as input to csctl.

[garloff]

Well, possible.
What I see is that csctl finds something openstack-hosted-control-plane related on the OCI server and that makes it trip.
There is nothing openstack/hosted-control-plane related in my repository (which I am trying to publish) and this seems to confuse csctl. Somehow it seems to validate something that is completely unrelated to what I want csctl to do:

• Determine the next free version (v5)
• Tag and push out the release artifacts to OCI registry

As pushing out git-tagged stuff works, it really seems to be related to the determination of the version number, which is only done with -m stable. Looks like I will have to read the code myself, sigh.

[garloff]

Looks to me like openstack-hosted-control-plane-1-34-v0-... is not a name that csctl can deal with.
Could make this openstack-hosted_control_plane-1-34-v0-... or openstack-hostedControlPlane-1-34-v0-... or change the string handling functions to deal with $PROVIDER-$ANYTHING-$MAJ-$MIN-v$VER[$OPT] with - allowed in $ANYTHING. Making parsing robust is non-trivial as $OPT starts with -, but is optional, so we'd first have to detect whether it's there before we can count the - from the right side. Or we disallow a - in $ANYTHING to be followed by a digit.

[garloff]

Looks like we'd need to adjust NewFromClusterClassProperties() and NewFromClusterStackReleaseProperties()
in vendor/github.com/SovereignCloudStack/cluster-stack-operator/pkg/clusterstack/clusterstack.go

[jschoone]

Looks to me like openstack-hosted-control-plane-1-34-v0-... is not a name that csctl can deal with. Could make this openstack-hosted_control_plane-1-34-v0-... or openstack-hostedControlPlane-1-34-v0-... or change the string handling functions to deal with $PROVIDER-$ANYTHING-$MAJ-$MIN-v$VER[$OPT] with - allowed in $ANYTHING. Making parsing robust is non-trivial as $OPT starts with -, but is optional, so we'd first have to detect whether it's there before we can count the - from the right side. Or we disallow a - in $ANYTHING to be followed by a digit.

They were renamed to hostedcontrolplane back then (end of January) since CSO uses the dashes as separators and underscores and capitals are not allowed in Kubernetes resource names. I tinkered with oras directly so I didn't get any errors with the name and didn't expect it could lead to problems with other cluster stacks, sorry. I removed the old hosted-control-plane tags now

imho we don't need to change something in the code this direction since the impact would be too big. It might be more useful to let csctl only check for the Cluster Stacks it builds and ignore the other, because if we just fix the dashes it could be something else next time. Even more important is to just keep the repo clean. It was my fault to not remove those tags directly after I saw they do not work and I will be more careful with that.