I don't understand why you need this feature. Can you explain what's your use case?

RHEL 8 does not deliver any modules with a static context. Hence there is no reason for porting back this libmodulemd's feature into RHEL 8.4. Even if we enhanced libmodulemd, it would not help you because DNF (libdnf) in RHEL 8.6 does NOT support static contexts. libdnf's bug #2007167 was not about adding a support for static context. It was about not erroring on modules with an unknown modulemd field by ignoring the unknown fields.

Moreover, Red Hat, in general, does not add new features into older RHEL minor releases. You would need to contacting Red Hat support <https://access.redhat.com/support/> for getting an exception.

The Extended Update Support (EUS) is a regular update of newer fixes and selected capabilities into prior minor releases. It is done explicitly to maintain the support level requirements of vendors like SAP who only support certain release versions.

As for the error. It is the EXACT SAME error as referenced in the previous bug but it applies to 8.4 **EUS**

As noted above, the strict validation commentary was copied from the previous bug reference. As for the reference to 2007167 about not erroring on modules with an unkown modulemd field... that is the same fix I am looking for--, to bypass the strict validation that causes the errors.

Here is the output of trying to do an update with the error:

============

[root@XXXXXX]# dnf update
Updating Subscription Management repositories.
Last metadata expiration check: 3:00:48 ago on Wed 06 Apr 2022 04:44:51 AM CDT.
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Dependencies resolved.
Nothing to do.
Complete!
[root@XXXXXX]#

============

Here are the EUS repos readout with the error

============

[root@XXXXXX]# dnf update --refresh
Updating Subscription Management repositories.
Red Hat Enterprise Linux 8 for x86_64 - SAP NetWeaver - Extended Update Support (RPMs)     11 kB/s | 4.0 
Red Hat Enterprise Linux 8 for x86_64 - AppStream - Extended Update Support (RPMs)         14 kB/s | 4.5  
Red Hat Enterprise Linux 8 for x86_64 - SAP Solutions - Extended Update Support (RPMs)    9.7 kB/s | 4.0   
Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support (RPMs)            11 kB/s | 4.1   
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Dependencies resolved.
Nothing to do.
Complete!
[root@XXXXXX]#

============

(In reply to Bill Wood from comment #2)
> The Extended Update Support (EUS) is a regular update of newer fixes and
> selected capabilities into prior minor releases. It is done explicitly to
> maintain the support level requirements of vendors like SAP who only support
> certain release versions.
> 
Selected. And for the selection there must be an official request through Red Hat support. Bugzilla is not a support tool.

> As for the error. It is the EXACT SAME error as referenced in the previous
> bug but it applies to 8.4 **EUS**
> 
> As noted above, the strict validation commentary was copied from the
> previous bug reference. As for the reference to 2007167 about not erroring
> on modules with an unkown modulemd field... that is the same fix I am
> looking for--, to bypass the strict validation that causes the errors.
> 
Yes. But the error is not in libmodulemd. The error is in libdnf <https://github.com/rpm-software-management/libdnf/pull/1346/commits/4f1cab4b4080933cc3174e76961c83dac725c12a>. You are complaining at a wrong place. I'm moving this bug report to libdnf component since the only thing you are asking is ignoring the error message.

> ============
> 
> Here are the EUS repos readout with the error
> 
> ============
> 
> [root@XXXXXX]# dnf update --refresh
> Updating Subscription Management repositories.
> Red Hat Enterprise Linux 8 for x86_64 - SAP NetWeaver - Extended Update
> Support (RPMs)     11 kB/s | 4.0 
> Red Hat Enterprise Linux 8 for x86_64 - AppStream - Extended Update Support
> (RPMs)         14 kB/s | 4.5  
> Red Hat Enterprise Linux 8 for x86_64 - SAP Solutions - Extended Update
> Support (RPMs)    9.7 kB/s | 4.0   
> Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support
> (RPMs)            11 kB/s | 4.1   
> Module yaml error: Unexpected key in data: static_context [line 9 col 3]
> Module yaml error: Unexpected key in data: static_context [line 9 col 3]
> Dependencies resolved.
> Nothing to do.
> Complete!
> [root@XXXXXX]#
> 
> ============

You should complain to a vendor of "SAP NetWeaver - Extended Update" or "SAP Solutions - Extended Update". You can use "dnf update --repoid=..." command to pinpoint which repository of the two brings the unsupported content. Static context is not supported in any RHEL 8. The vendor should not use that feature. The fact that RHEL-8.6 DNF does not errors on it does not mean that DNF handles the static-context modules as a static context.

Thank you for the feedback. The EUS REPOs are official Red Hat versions. They are designed to bring in fixes and updates from later minor versions while retaining the existing release for long term support requirements from vendors like SAP.

I know what EUS repos are. They do not contain any module with the offending static_context keyword. There is no problem with them. The offending module is in one of "SAP NetWeaver - Extended Update" or "SAP Solutions - Extended Update" repositories. They are not provided by Red Hat.

(In reply to Petr Pisar from comment #5)
> I know what EUS repos are. They do not contain any module with the offending
> static_context keyword. There is no problem with them. The offending module
> is in one of "SAP NetWeaver - Extended Update" or "SAP Solutions - Extended
> Update" repositories. They are not provided by Red Hat.

My fault. The two quoted repositories are indeed delivered by Red Hat. I wasn't aware about them.

However, they do not to contain static-context modules. You probably got the offending module from some other repository which is now disabled, but still cached by DNF.

It seems that the best approach will be patching libdnf in RHEL 8.4 EUS by Red Hat.

(In reply to Petr Pisar from comment #12)
> (In reply to Petr Pisar from comment #5)
> > I know what EUS repos are. They do not contain any module with the offending
> > static_context keyword. There is no problem with them. The offending module
> > is in one of "SAP NetWeaver - Extended Update" or "SAP Solutions - Extended
> > Update" repositories. They are not provided by Red Hat.
> 
> My fault. The two quoted repositories are indeed delivered by Red Hat. I
> wasn't aware about them.
> 
> However, they do not to contain static-context modules. You probably got the
> offending module from some other repository which is now disabled, but still
> cached by DNF.
> 
> It seems that the best approach will be patching libdnf in RHEL 8.4 EUS by
> Red Hat.

No problem. If it is another repo or old installed artifact I will live with it until 8.6 is released in a month or so. It is just an SAP Test/Development system and it isn't causing any SAP system issues right now. I believe the strict validation is resolved with 8.6 from one of the bug reports I saw. And SAP supports all of the even numbered minor releases so that should be good.

Thank you for looking into this.

(In reply to Bill Wood from comment #0)
> Description of problem: 
> 
> Similar to 2007167 which was logged for 8.6 beta. However, this bug also
> affects 8.4 EUS. May have been introduced through libdnf updates dates on
> 3/8/2022.
> 
> -- From previous submission
> 
> This is caused by DNF which explicitly strictly validates modulemd-v2
> documents before using them. 
> 
> Since the old libmodulemd 2.9.4 does not recognize static_context field, it
> reports that the document is not strictly valid and DNF will discard it.
> Because DNF discards all documents in a modular repository, it errors with
> "No available modular metadata for modular package".
> 
> DNF needs stop strictly validating the documents. Without strict validation,
> old libmodulemd will ignore unknown fields and DNF will happily consume them.
> 
> You can work around the DNF issues by upgrading libmodulemd first. Then
> subsequent invocations of DNF will recognize the same documents as valid.
> Because you use DNF for updating libmodulemd (and dnf, once fixed), you need
> temporarily disable modular repositories "dnf --disable-repo
> 'fedora-modular*' upgrade libmodulemd".
> 
> 
> Version-Release number of selected component (if applicable):
> 
> libmodulemd-2.9.4-2.el8.x86_64
> libdnf-0.55.0-7.el8.x86_64
> 
> 
> Failure results:
> 
> - dnf update fails to process and produces error Module yaml error:
> Unexpected key in data: static_context [line 9 col 3]
> 
> 
> Additional info:
> 
> RHEL 8.4 (EUS) - SAP Development / Test / Demo System
> Release is set to 8.4 for SAP support requirement, however, additional
> updates are processed through EUS.
> 
>     --> Module yaml error: Unexpected key in data: static_context [line 9
> col 3]
> 
> A posted workaround is to update update libmodulemd, however, with Release
> set to 8.4 to comply with SAP support this is not an option. 
> 
> This is a verified bug in 2007167 for 8.6 beta. If the 8.6 fix will be
> backported into 8.4 EUS then this bug can be closed. Otherwise it is valid
> for this version.

Bill, we should not create zstream BZ directly. The zstream process needs to be followed in order to avoid regressions upstream/downstream.  
The 8.4 zstream BZ had to be cloned from the RHEL 8.6 BZ.

After a discussion with Teodor closing as NOTABUG, as this BZ has been re-purposed for ITR 8.7, but the bug has already been fixed in 8.6 Y stream, hence it will not be present in 8.7.

The bug for 8.4 Z stream release is https://bugzilla.redhat.com/show_bug.cgi?id=2081002