context is mandatory in modularity metadata about yum-packaging-precompiled-kmod HOT 8 CLOSED

Thank you @stdweird for reporting this.

I've asked Red Hat for guidance on how to generate that hash value. The comment above it says

The exact mechanism for generating the hash is unspecified.

from yum-packaging-precompiled-kmod.

@kmittman i'm not sure what you mean with "asked Red Hat", but if you want, i can open a support case (or better, reopen one)
i am trying to convince nvidia support that they have the same issue on their official el8 yum repos

from yum-packaging-precompiled-kmod.

Yes, that would be helpful if you could open a support case (and please forward me the bug id).

By repository do you mean https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/ ?
That is also maintained by my team and the YAML file is generated using the genmodules.py script here on GitHub.

from yum-packaging-precompiled-kmod.

@kmittman ah, then you are the person to talk to. our original case was 02740416, i just opened https://access.redhat.com/support/cases/#/case/02808189

From the original case:

Doing quick research, we can see that a context is an option that was created to fix the problem when creating multiples module builds for a single dist-git commit of a modulemd file.

Today, we uniquely identify a module build in a variety of systems with <name>-<stream>-<version> (NSV) where version is derived from the dist-git commit timestamp. Here we’ll have an httpd-2.4 module built on f26 and an http-2.4 module built on f27: two different module builds with the same name, stream, and version. How can we tell them apart?

We will introduce a new value called the context of a built module and include it in the modulemd metadata that gets carried with the built module.

For user facing cases (dnf installation) it will generally be hidden. The old NSV value will still appear. If a user ever needs to surface the value, client tooling can find it in the modulemd metadata. The additional identifier will give users access to explicit pointers to the content that is installed:
For cloning a machine.
For comparing two installed hosts.
For reporting bugs.
Some build and compose time systems will have to be modified to use the context as part of a new unique identifier. NSVC will be the <name>-<stream>-<version>-<context>. The systems in question are PDC, koji/brew, pungi, and bodhi.

The context value will be a hash, generating as the first step in the build process (but after expansion). Consider what metadata needs to be hashed: we think that hashing the whole modulemd is problematic, because the modulemd can and will be modified after build time. Therefore, the context_hash value will need to be derived from only the stuff that uniquely identifies the build and runtime context of the module -- name, stream, version and crucially, its dependencies.

For more details, please access https://docs.fedoraproject.org/en-US/modularity/architecture/consuming/dnf-behavior/ and https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/StreamExpansion#New_Problems.

from yum-packaging-precompiled-kmod.

I did some asking around and as far as I can tell the quote from @stdweird is accurate, hash the (name, stream, version, dependencies) and truncate it to 10-12 characters. I was told 12 characters max for the current specification, but apparently it's being changed: https://github.com/fedora-modularity/libmodulemd/blob/c64837f31fd1eef37836f5aa376c40984b7edb15/yaml_specs/modulemd_stream_v3.yaml#L77. What I was told was:

As long as they aren't doing stream expansion, it won't matter. The context is for differentiating against the same module:stream:version that's built against two different buildroots. The important part is uniqueness.

from yum-packaging-precompiled-kmod.

Okay I opened a pull request #17 for the proposed change, ex: context: ab14487fb703. Generated a new YAML file modules.yaml (attached), which can be compared to what is currently in the repository: modules.yaml.gz
note: the only differences should be the version key-values (timestamp based) and addition of context key-values

from yum-packaging-precompiled-kmod.

This change is now in the repository.

1. Entry point: https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/repodata/repomd.xml
2. repomd.xml points to 4f1cac1a3d52e5d053963f899db9f89b2d68db01961a7259048666570b1d3dd5-modules.yaml.gz
3. YAML file

document: modulemd
version: 2
data:
name: nvidia-driver
stream: latest
version: 20201123080310
context: 750b3266c2ee

Closing. @stdweird please re-open if this still does not work for you.

from yum-packaging-precompiled-kmod.

@kmittman thanks a lot. i confirm that satellite can now sync the repo without issues

from yum-packaging-precompiled-kmod.