Do you have the bugzilla link?
I hope the fix will also correct the synced packages with the missing filelist in the database. A complete, validated repository sync doesn‘t seem to affect that part…
I would voice that concern on the redmine issue. I imagine that would be fixed as well, but it’s good to check.
Go figure that I hit this bug the day I decide to light up Katello 4.1 and insert A centos-8-clone-like repository (in my case, Rocky Linux 8.4).
I was right in an early commment on a related post of mine that this was pulp. Ha!
I will comment in my post the link to the bug listed above by @gvde
I just wrote a message in pulp isssue #9107.
I looked at the code of the PR and it seems to me as if there are functions to validate the synced data in the database with the original metadata in the source repository. So if I am not mistaken that is there, it’s unclear to me if that works automatically during each sync or if that requires a special pulp repair call from katello like the validated complete sync…
I quote the answer from the pulp issue here to have all the relevant information in this topic, too:
Most likely we will just write a script that will do an in-place repair - it hasn’t been decided yet whether Katello would do anything to run it automatically. My assumption is - probably not.
We’ll try to get 3.14.0 released by the end of the day (Thursday), which should let Katello package it by the end of the week. And then once that’s out we’ll evaluate the best way to address any existing issues.
O.K. There is hope here… Wait until the pulp-rpm 3.14.0 package to get the correct data in for future syncs. Then run a in-place repair. And it’s hopefully all up to speed again…
2 Likes
So when I eventually get the new pulp, what’s the “in-place repair” process?
It seems pulp_rpm 3.14.0 is out. So I guess next step would be foreman/katello packaging…
@iballou @jjeffers There also seems to be a script available if all RPMs have been downloaded. I guess that means if you have download policy “immediate” and not “on demand”.
I hope it’ll soon gets into the katello repositories and we can get away from that broken version. By now, I have quite a few updates in the queue and I started doing updates from the centos mirrors because some are overdue for more than a week now…
Just wanted to let you all know that we’re in the process of testing out the Pulp team’s fixing script. I’m not sure how it’ll be delivered but we’ll keep you updated.
1 Like
Excellent. Well will the new pulp_rpm package be available? The sooner I stop syncing rpms with broken metadata into the system, the better. Repairing would be the second step for me…
I wonder what the repair script does exactly. Can it find all RPMs with have broken metadata or does it simply go through everything and compares & repairs it if it is not matching with what it should be?
Is this going into 4.1.2? I really don’t quite understand where to look to see what’s going into an upcoming release… If it’s going into 4.1.2 and I can expect 4.1.2 very soon, I would wait. Otherwise, I am tempted to patch my 4.1.1 to get my installation working again…
I have just tested the repair script from Issue #9107: filelists and changelog metadata is not parsed properly - Pulp saves incorrect filelists and changelog metadata and generates incorrect metadata - RPM Support - Pulp and it seems to work. Ran the script as user pulp. I seem to have 94 packages in the system which really have no filelist and not changelogs and thus keep getting “repaired” during each run.
Now, when I try to republish repository metadata for all repositories, it fails for the baseos repository of centos 8 and centos 8 stream. I get the same error which I have got for the sync, i.e. as described in CentOS 8.4 BaseOS Sync error
Too many bugs… I’ll have to wait for 4.1.2, I guess…
4.1.2-1 is available. Does this fix the issue?
Yes. It fixes the sync. I have just updated. However, you still need to run the repair script to fix the filelists for all packages which have been sync from the remote repositories with 4.1.1.
So basically what I did:
- update to 4.1.2 (main server and content proxies)
- stop all foreman-services (main server and content proxies)
- run foreman-installer (main server and content proxies)
on main server:
4. run repair
5. Start a new complete sync of all repositories I have. (I did the complete sync out of precaution but I think it’s not necessary).
6. Published and promoted a new content view version for all my content views.
7. I ran a complete sync for the content proxy as a precaution although I think the optimized sync which now runs automatically with content view promotion did fix everything.
Not sure how to run the repair.py script. I’m running it as user pulp, but get this output:
-bash-4.2$ python3 repair.py
Traceback (most recent call last):
File "repair.py", line 8, in <module>
django.setup()
File "/usr/lib/python3.6/site-packages/django/__init__.py", line 19, in setup
configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
File "/usr/lib/python3.6/site-packages/django/conf/__init__.py", line 79, in __getattr__
self._setup(name)
File "/usr/lib/python3.6/site-packages/django/conf/__init__.py", line 64, in _setup
% (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting LOGGING_CONFIG, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.
-bash-4.2$
The complete command is in the pulp ticket:
# DJANGO_SETTINGS_MODULE=pulpcore.app.settings PULP_SETTINGS=/etc/pulp/settings.py python3 repair.py
@iballou Now that 4.1.2 with pulp_rpm 3.14.0 is out for EL7 what is the plan for the repair script? I don’t see anything mentioned in the release announcement or the changelog…
Here is an email from pulp-list@redhat.com: Re: [Pulp-list] pulp_rpm 3.14.0 is Generally Available (important info!)
Looks like the repair script will simply live on the issue like it does now.