Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"00000000" modular context chomped to "0" #3454

Open
ianballou opened this issue Mar 4, 2024 · 15 comments
Open

"00000000" modular context chomped to "0" #3454

ianballou opened this issue Mar 4, 2024 · 15 comments
Labels

Comments

@ianballou
Copy link
Contributor

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

@evgeni
Copy link
Member

evgeni commented Mar 4, 2024

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)

@ianballou
Copy link
Contributor Author

ianballou commented Mar 4, 2024

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

@dralley
Copy link
Contributor

dralley commented Mar 4, 2024

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?

@dralley
Copy link
Contributor

dralley commented Mar 4, 2024

Couldn't reproduce on 3.23 either.

@dralley
Copy link
Contributor

dralley commented Mar 5, 2024

This probably happened at some point prior to #3346 being resolved. Or maybe you don't have #3346 in your build?

Can you tell us the exact version of pulp_rpm you are running

@dralley
Copy link
Contributor

dralley commented Mar 5, 2024

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.

@dralley
Copy link
Contributor

dralley commented Mar 5, 2024

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.

@WerVa
Copy link

WerVa commented Mar 5, 2024

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

@dralley
Copy link
Contributor

dralley commented Mar 19, 2024

Would it be problematic to try deleting the repo, performing orphan cleanup, and then re-syncing it, to see if it is ultimately fixed?

@WerVa
Copy link

WerVa commented Mar 20, 2024

I tried this but the error still occurred
https://community.theforeman.org/t/excluding-php-updates-in-foreman/36181/4?u=werva

@quba42
Copy link
Contributor

quba42 commented Mar 21, 2024

@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.

@WerVa
Copy link

WerVa commented Mar 21, 2024

Installed python3.11-pulp-rpm version:
python3.11-pulp-rpm-3.23.3-1.el8.noarch

@pedro-psb
Copy link
Member

@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
Copy link
Contributor

quba42 commented Apr 23, 2024

@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.

@ianballou
Copy link
Contributor Author

ianballou commented Apr 23, 2024

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:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants