Glasskube Support

[kosmoz]

Tell us more.

Glasskube is a package manager for Kubernetes clusters. Glasskube and Glasskube packages can be managed via GitOps solutions, such as Flux or ArgoCD, in which case our users would love to get notified about updates directly in their repositories.

[kosmoz]

New package manager questionnaire

Did you read our documentation on adding a package manager?

• I've read the adding a package manager documentation.

Basics

What's the name of the package manager?

Glasskube

What language(s) does this package manager support?

Glasskube is a package manager for Kubernetes. Glasskube packages are usually written as Kubernetes manifests in YAML files.

How popular is this package manager?

On GitHub: Currently, close to 1k stars, 79 forks, 28 contributors.

Does this language have other (competing?) package managers?

• Yes (give names).
• No.

1. Helm
2. Timoni
3. Operator Lifecycle Manager

What are the big selling points for this package manager?

• Focus on ease of use
• Dependency aware
• Central repository for most popular projects
• Multi repository support (incl. private repositories)

Detecting package files

What kind of package files, and names, does this package manager use?

Every file that can contain Kubernetes manifests can also contain Glasskube packages.

Which fileMatch pattern(s) should Renovate use?

The default fileMatch for the kubernetes manager can also be used: []

Do many users need to extend the fileMatch pattern for custom file names?

• Yes, provide details.
• No.

Similar to kubernetes, the user has to specify where the manifests are located.

Is the fileMatch pattern going to get many "false hits" for files that have nothing to do with package management?

Possibly, depending on user config. With the default config: no.

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

A Glasskube package may specify a repository name, which is a reference to another kind of Kubernetes resource: PackageRepository.
The PackageRepository contains information about how and from where package metadata (such as available versions) can be retrieved.

A package does not link to other packages.

Package file parsing method

The package files should be:

• Parsed together (in serial).
• Parsed independently.

Which format/syntax does the package file use?

• JSON
• TOML
• YAML
• Custom (explain below)

How should we parse the package files?

• Off the shelf parser.
• Using regex.
• Custom-parsed line by line.
• Other.

Does the package file have different "types" of dependencies?

• Yes, production and development dependencies.
• No, all dependencies are treated the same.

List all the sources/syntaxes of dependencies that can be extracted

Glasskube packages are identified by having the following YAML fields:

apiVersion: packages.glasskube.dev/v1alpha1
kind: Package

The following fields are relevant for extraction:

• .spec.packageInfo.name
• .spec.packageInfo.version
• .spec.packageInfo.repositoryName

Describe which types of dependencies above are supported and which will be implemented in future

Apart from Glasskube packages, it would be fantastic if users could update the Glasskube installation itself using Renovate. Something similar already exists for Flux, so maybe this could be taken as inspiration.

Versioning

What versioning scheme does the package file(s) use?

We use a slightly extended variant of SemVer 2.0, where the build identifier is a number and must also be considered when comparing version strings

Does this versioning scheme support range constraints, like ^1.0.0 or 1.x?

• Supports range constraints (for example: ^1.0.0 or 1.x), provide details.
• No.

Lookup

Is a new datasource required?

• Yes, provide details.
• No.

Glasskube uses it's own package registry format.
Available versions of a package can be retrieved via <registryBaseUrl>/<packageName>/versions.yaml (e.g. https://packages.dl.glasskube.dev/packages/cert-manager/versions.yaml).
The registryBaseUrl can be extracted from the PackageRegistry resource with the right name (see below).
versions.yaml has the following structure:

latestVersion: v1.2.3
versions:
  - version: v1.2.3
  # ...

Will users want (or need to) set a custom host or custom registry for Renovate's lookup?

• Yes, provide details.
• No.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed.
• In the package file(s), provide details.
• In some other file inside the repository, provide details.
• User needs to configure Renovate where to find the information, provide details.

A basic PackageRepository looks like this:

apiVersion: packages.glasskube.dev/v1alpha1
kind: PackageRepository
metadata:
  name: custom
spec:
  url: https://packages.example.com/

The .spec.url can be used as repositorybaseUrl for packages where the packages .spec.packageInfo.repositoryName equals the repositories .metadata.name.
This example is a public repository.
Private repositories are also supported, but the authentication credentials might not be present in the repository in most cases.
In these cases it is probably necessary to configure renovate to use specific authentication credentials.

Are there any constraints in the package files that Renovate should use in the lookup procedure?

• Yes, there are constraints on the parent language (for example: supports only Python v3.x), provide details.
• Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details.
• Yes, some other kind of constraint, provide details.
• No constraints.

Will users need the ability to configure language or other constraints using Renovate config?

• Yes, provide details.
• No.

Artifacts

Does the package manager use a lock file or checksum file?

• Yes, uses lock file.
• Yes, uses checksum file.
• Yes, uses lock file and checksum file.
• No lock file or checksum.

Is the locksum or checksum mandatory?

• Yes, locksum is mandatory.
• Yes, checksum is mandatory.
• Yes, lock file and checksum are mandatory.
• No mandatory locksum or checksum.
• Package manager does not use locksums or checksums.

If lockfiles or checksums are used: what tool and exact commands should Renovate use to update one (or more) package versions in a dependency file?

Package manager cache

Does the package manager use a cache?

• Yes, provide details.
• No.

Currently, we only have in-memory caching for performance.

If the package manager uses a cache, how can Renovate control the cache?

• Package manager does not use a cache.
• Controlled via command line interface, provide details.
• Controlled via environment variables, provide details.

Should Renovate keep a cache?

• Yes, ignore/disable the cache.
• No.

Generating a lockfile from scratch

Renovate can perform "lock file maintenance" by getting the package manager to generate a lockfile from scratch.
Can the package manager generate a lockfile from scratch?

• Yes, explain which command Renovate should use to generate the lockfile.
• No, the package manager does not generate a lockfile from scratch.
• No, the package manager does not use lockfiles.

Other

What else should we know about this package manager?

[secustor]

Can package files have "local" links to each other that need to be resolved?
A Glasskube package may specify a repository name, which is a reference to another kind of Kubernetes resource: PackageRepository.
The PackageRepository contains information about how and from where package metadata (such as available versions) can be retrieved.

That would require an implementation of extractAllPackageFiles to process all matching files at once. That allows to dynamically find the yaml files containing Repository and adding the necessary informations to the extracted dependencies.
Additionally support for registryAlias is needed for the case there is no Repository kind in the repo.

What versioning scheme does the package file(s) use?
We use a slightly extended variant of SemVer 2.0, where the build identifier is a number and must also be considered when comparing version strings

Please add an example of this additional identifier. Is it simply a fourth digit?

Describe which types of dependencies above are supported and which will be implemented in future
Apart from Glasskube packages, it would be fantastic if users could update the Glasskube installation itself using Renovate. Something similar already exists for Flux, so maybe this could be taken as inspiration.

Please add more details to that. Is there a file which defines the Glasskube version?

[kosmoz]

Can you create a reproduction repo, with a PR which should be the desired update Renovate should generate? I'm currently failing to see the workflow outside of updating Package manifests.

Sure, check out this repo: https://github.com/kosmoz/renovate-upgrade-glasskube

Let me know if you have any questions! 🙂

[secustor]

Hmm, seems this specific scenario would be currently fit more a postUpgradeTask rather than native implementation currently as there is not standard file which contains the current version and a folder or file which contains the manifests.

That being said if you could an example for Package and PackageRepository then I would move this part to an issue.

[kosmoz]

That being said if you could an example for Package and PackageRepository then I would move this part to an issue.

Alright, here is a PR that would update the cert-manager package: kosmoz/renovate-upgrade-glasskube#2

[viceice]

it would be nice if glasskube adds a commend to the beginning, like Flux. so renovate can detect the version of the used cli to generate.

[kosmoz]

Hi, sorry for the delayed reply!

To clarify, do you mean it would be nice for the extended support, which @secustor said would be fit as a postUpgradeTask, or for what is currently implemented?

For the former, I think this is a great idea and we should consider it. For the latter I'm afraid it's not possible because we don't manage those YAML files directly, they are generally user-created.

[secustor]

Issue has been created: #29322