Discuss: maintaining and updating potentially large lists of CRD references in a library's config.jsonnet

[frimik]

Tooling and format for CRD references (index) maintenance

As mentioned in https://github.com/jsonnet-libs/k8s/pull/516#issue-2958117165 I was thinking a bit about how certain libraries (operators, controllers) grow, it's no longer commonly one single CRD, there are sometimes a multitude. Personally the copy-pasting and potentially manual altering of the upstream list is tedious for those larger libs where it's not just as simple as copying a single CRD URL.

You could even miss adding a CRD if you're not carefully comparing the upstream old vs new CRD list. Some tooling may be suitable to aid.

Even though my example used vendoring, I don't think upstream "raw" vendoring, as in my extreme case, is a proper solution... it will get messy. But some practices around local indexing formats may be something to think about... for example maybe a simple ./index/0.15.json for index keeping is a good practice?

local indexed_versions = [ // since 0.15
  { output: '0.15', version: '0.15.1', crds: (import './index/0.15.json').crds },
];

{
  "prefix": "^io\\.external-secrets\\..*",
  "crds": [
    "external-secrets.io_clusterexternalsecrets.yaml",
    "external-secrets.io_clusterpushsecrets.yaml",
    "...",
    "generators.external-secrets.io_stssessiontokens.yaml",
    "generators.external-secrets.io_webhooks.yaml"
  ]
}

I've been using various methods... curl, fully manual copy-pasting... kustomize localize to get a local copy of the upstream kustomize references for easily converting a directory list of yaml files into the resulting jsonnet list for example ...

@Duologic mentioned "central management" as a topic as well.. I have no quarrels so far with that. This is a great "service" 💯. Any delays in getting MRs done is easily self-vendored as a workaround.

Best, Mike