Unable to set a label containing a guid on an existing cluster (works for a new cluster)

[jose-joye]

I'm currently using pgo 4.5.1. However, this behavior also occurs in pgo 4.2.2.

# creating a cluster with a label containing a guid (in fact any string starting with a number) works
pgo -n cfae-bit-cbcd create cluster jj-label-ok --labels=uuidref=822b5bf1-3a28-46b1-a09a-75b58cfee2ed

pgo -n cfae-bit-cbcd show cluster jj-label-ok
$ pgo -n cfae-bit-cbcd show cluster jj-label-ok

cluster : jj-label-ok (crunchy-postgres-ha:centos7-11.10-4.5.1)
        pod : jj-label-ok-6c6984766b-hbdmf (Running) on worker32.ccp02.mkm.mycompany.ch (2/2) (primary)
                pvc: jj-label-ok (8Gi)
        resources : Memory: 128Mi
        deployment : jj-label-ok
        deployment : jj-label-ok-backrest-shared-repo
        service : jj-label-ok - ClusterIP (10.111.176.146) - Ports (9187/TCP, 2022/TCP, 5432/TCP)
        labels : crunchy-postgres-exporter=true name=jj-label-ok pg-cluster=jj-label-ok pg-pod-anti-affinity= workflowid=16326d54-b336-4c2b-a255-0da86a14d84c autofail=true crunchy-pgbadger=false pgo-backrest=true pgo-version=4.5.1 pgouser=admin uuidref=822b5bf1-3a28-46b1-a09a-75b58cfee2ed crunchy-pgha-scope=jj-label-ok deployment-name=jj-label-ok

However, adding such a label to an existing cluster fails (in fact any string starting with a number) :

pgo -n cfae-bit-cbcd label jj-label-ok --label=myuuid=6e0f78ce-e682-4ee2-88c2-a961245123cb
Error: labels not formatted correctly

If the guid start with a letter, then it is fine...

pgo -n cfae-bit-cbcd label jj-label-ok --label=myuuid=ae0f78ce-e682-4ee2-88c2-a961245123cb
Label applied on jj-label-ok

To what I can see, applying a label containing a guid is used in several cases:

• workflowid
• pgo-osb-instance

This behavior is the same if we use the REST API instead of the pgo-client.

In that sense, it may make sense to fix this behavior

Regards,
José

[jkatz]

I was able reproduced this. This is certainly a bug, I'll see about getting a fix.

[jkatz]

Fixed and backpatched down to 4.4. I may need to check a few more spots to see how we're handling label parsing, though any adjustments to that would likely just be 4.6.

Thanks for reporting!

[jkatz]

#2219 refines the behavior a bit further to ensure it's consistent across labeling mechanisms. Additionally, it will introduce an improved syntax for adding and managing labels for 4.6.