pulp
"00000000" modular context chomped to "0"
Version Pulp-RPM 3.23 (maybe any version?)
Describe the bug When syncing https://rpms.remirepo.net/enterprise/9/modular/x86_64/, the context for module streams like "php:remi-7.4" is indexed into Pulp as "0" when it should be "00000000".
This causes applicability bugs in Katello which makes things look upgradable when they aren't.
To Reproduce Sync https://rpms.remirepo.net/enterprise/9/modular/x86_64/
Take a look at the modular context vs what's in the upstream repo's repodata.
Expected behavior Context should be "00000000" instead of "0" to match the upstream
Additional context Community issue: https://community.theforeman.org/t/excluding-php-updates-in-foreman/36181/9
context: 00000000 means "the key context has the integer value 00000000", which is identical to 0.
IMHO those need to be quoted to be interpreted as strings (which contexts are)
On one hand, sticking to the yaml guidelines is best since it already has a large ruleset defined. On the other hand, we know that modular context will always be a string. I suppose whatever we do, the upstream repo owner should consider adding quotes in the repodata if possible. It makes me wonder if the repodata generation tool is failing to do so...
Edit: remi repo support forum for any future readers: https://forum.remirepo.net/viewforum.php
I attempted to reproduce this on the latest master branch, unsuccessfully. I'll try 3.23 also.
Any chance this could have happened a while back, on a much older version, and it just wasn't noticed until recently?
This probably happened at some point prior to https://github.com/pulp/pulp_rpm/pull/3346 being resolved. Or maybe you don't have https://github.com/pulp/pulp_rpm/pull/3346 in your build?
Can you tell us the exact version of pulp_rpm you are running
It looks like the latest 6.15 snap does NOT have this fix, or any other fixes, it's using 3.23.0 from last October.
This BZ is on the 6.15.0 train (I think) and it's already pulling in 3.23.3, so we might not need to do anything, it will probably get pulled in at some point.
Well I did try reverting that commit and I still wasn't able to reproduce. Maybe something else? IDK.
In any case please confirm if this was a fresh system or not.
in my case it is not a fresh system and the pulp rpm version is rubygem-pulp_rpm_client-3.23.0-1.el8.noarch
Would it be problematic to try deleting the repo, performing orphan cleanup, and then re-syncing it, to see if it is ultimately fixed?
I tried this but the error still occurred https://community.theforeman.org/t/excluding-php-updates-in-foreman/36181/4?u=werva
@WerVa The RPM version that is truly relevant here isn't the rubygem-pulp_rpm_client, but the python3.11-pulp-rpm version. (Note that the python version might be something other than 3.11 in your case.) In Katello land the plugin itself often has a somewhat newer version than the client bindings used.
Installed python3.11-pulp-rpm version: python3.11-pulp-rpm-3.23.3-1.el8.noarch
@quba42 So having an older binding should not interfere with using a newer version of a pulp component, right?
I tried to reproduce on a pulp's development environment, but with no luck. I can see the zeroes chomped in 3.23.0 but not in 3.23.3. Tried with both on_demand and immediate sync policies.
@quba42 So having an older binding should not interfere with using a newer version of a pulp component, right?
So long as they use the same Y-version there should not normally be any problems. So 3.23.0 client would be expected to work with 3.23.3 plugin. Katello also has a battery of tests to ensure the particular client version they use does not have any issues with the particular plugin version they use.
~~I just tested this on python3.11-pulp-rpm-3.23.0-2.el8.noarch in Katello 4.11 and did not see the chomped zeros. I tested complete mirroring, content-only mirroring, and additive mirroring.
I then upgraded to 3.23.0, deleted the repo and cleaned up orphaned content, and then tried again. Still I see all the zeros. After upgrade I only tested content-only mirroring since I'm guessing it's a question about Pulp's generated modular metadata here.~~
Edit: forgot the issue was in the DB and not the metadata. Checking again.
Edit edit: reconfirmed that I cannot reproduce the issue with on-demand + content-only syncing: