master branch orders some resource names differently than v4.4.1

[ephesused]

Describe the bug

At v4.4.1 and before, kustomize build produces output with resource names sorted like so:

1. testing
2. testing-one
3. testing-two

In the master branch (I believe first appearing at 92197fd), kustomize build produces output with resource names sorted like so:

1. testing-one
2. testing-two
3. testing

Cross reference #4361 (comment)

Files that can reproduce the issue

kustomization.yaml

resources:
  - resources.yaml

resources.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: testing
data:
  key: value
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: testing-one
data:
  key: value
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: testing-two
data:
  key: value

Expected output, using v4.4.1 as an example

$ build/kustomize-execs/release-v4.4.1/kustomize version
{Version:kustomize/v4.4.1 GitCommit:b2d65ddc98e09187a8e38adc27c30bab078c1dbf BuildDate:2021-11-11T23:36:27Z GoOs:linux GoArch:amd64}
$ build/kustomize-execs/release-v4.4.1/kustomize build testdata/kust-resource-sort
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  name: testing
---
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  name: testing-one
---
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  name: testing-two
$

Actual output

$ cat build/kustomize-execs/branch-master/info.yaml
branch: master
sha1: 6e82b210a9e0651cc8392d2931c64348137b82ff
$ build/kustomize-execs/branch-master/kustomize build testdata/kust-resource-sort
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  name: testing-one
---
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  name: testing-two
---
apiVersion: v1
data:
  key: value
kind: ConfigMap
metadata:
  name: testing
$

Kustomize version

This change is not (yet) in a released version. I see the change in the master branch, and I believe it first appears at 92197fd.

Platform

Linux

[natasha41575]

Are you absolutely certain this behavior started showing up in 92197fd? I’m not sure how that could be the case because that PR doesn’t touch any of the code for kustomize build, it only adds a new sub command to kustomize edit.

Unfortunately I don’t have a laptop with me and won’t be able to verify myself for a few more days.

[ephesused]

When I build off ff7b2f2 (which I believe is the commit immediately prior to 92197fd), I see the v4.4.1 behavior. When I build off 92197fd, I see the changed behavior.

I'd appreciate someone double checking me here - it may be that I'm making a bad assumption or my builds are somehow flawed.

Edited to add: This analysis is incorrect. My mistake was that ff7b2f2's parent is b28f1e5 (not 92197fd).

[ephesused]

Poking around some more, I now believe it's 233f1a3. Looking at only the merge pull request commits marked as verified, I see that 75de98e matches v4.4.1, while 233f1a3 has the new sorting behavior.

My mistake was using ff7b2f2 as a comparison point. It's not a merge.

I've been out for a while, so everything is fuzzy. Apologies for my confusion.

[natasha41575]

Thank you, I have been able to reproduce this and can confirm that there is a different order from 4.4.1 and master. We should look into this before the next release.

/triage accepted
/kind bug

[natasha41575]

A possible reason is that perhaps in changing Gvk.String, we changed the output of Gvk.IsLessThan.

[ephesused]

Just a quick update to note that v4.5.0 includes this sequence change.

[seh]

As noted in the "kustomize" Slack channel, in my examples, it appears that kustomize is now sorting by "metadata.labels" before "metadata.name."

Reading further, that's not quite right either. I can't figure out the ordering within a given GVK ("apiVersion" and "kind") within a given Kubernetes namespace ("metadata.namespace").

[ephesused]

@seh, I haven't confirmed, but my uneducated guess is that the sorting is happening by way of ResId's String(), which means the sorting change would come from this change.

Assuming I'm reading everything correctly, I believe that would explain the test case in this ticket. The previous behavior was GVK, pipe, namespace, pipe, name. The new behavior is GVK, slash, name, period, namespace. So the previous would been sorting:

• GVK|namespace|testing
• GVK|namespace|testing-one
• GVK|namespace|testing-two

The new would be sorting:

• GVK/testing.namespace
• GVK/testing-one.namespace
• GVK/testing-two.namespace

The previous behavior was dealing with the hyphen (in "testing-one" and "testing-two") as a comparison based on a longer string. So "testing" comes before "testing-one" and "testing-two". The new behavior deals with the hyphen by determining it sorts before a period. So "testing-one" and "testing-two" come before "testing".

Again, the above analysis is based on a cursory review - I'm not certain that this is the cause.

[seh]

Ed, that's an excellent explanation. I stared at my diff for about five minutes, trying various explanations in my head, and none came any closer than "2-3-1," meaning that it was almost reversed, but the first and second items were swapped. Your explanation addresses the role of the hyphens in the names.

My examples are triples like "cert-manager," "cert-manager-cainjector," and "cert-manager-webhook." They now sort as follows:

• cert-manager-cainjector
• cert-manager-webhook
• cert-manager

You have now explained why that's so.

[KnVerey]

Thanks for the report and detailed reproduction steps. I'm really sorry that we released this regression. I have a PR up to fix it, added a note about it to the release 4.5 notes, and we will release 4.5.1 ASAP today.

[ephesused]

Thanks, @KnVerey. I see the fix in v4.5.1. Everything I run comes back exactly the same between v4.4.1 and v4.5.1.