Ok, well, I apologise, my post was a bit confrontational. But i am sick of these sorts of difficulties, so it is difficult to contain the frustration sometimes.
To address a few things you’ve claimed in your reply though:
you say “anything you can see in the UI, you can also access by API”.
First, I am trying to look in a logfile, because the info is not in the UI.
Second… come on. I’m trying to get foreman to work, because i need to accomplish something with it. If foreman can’t do the simplest thing like sync a redhat repository, where am I going to find the time to figure out how to use the API to debug a basic issue?
The information is not in my /var/log/messages. I’ve synced CentOS 7 repos successfully, and Red Hat 8 BaseOS repos successfully, and not a single downloaded rpm is listed in /var/log/messages.
Further, /var/log/messages is full of selinux spam, so foreman/katello devs need to address that also. I don’t have time to tweak 1000 selinux things to silence those warnings, and yet, the doco says foreman/katello needs selinux ON, so, i supposedly cannot just turn it off…
I am running foreman 2.4 / katello 4, on el8, because my old 2.3/3.16 installation failed miserably on the upgrade to katello 3.18. The pulp3 was completely broken, and I gave up on it.
If it works on EL7, but there are still a few issues with running foreman/katello on el8, I understand. But it largely seems to be working, so it must be very close to working reasonably well.
But it is still very frustrating that I can’t even find things like repository sync being logged properly, so that makes it difficult for me to even file a bug and provide useful info to developers.
Additionally, I’ve just discovered all the rpms now seem to be stored in nonsense-names “artifact” files, like:
I mean, really? That seriously does not help. Many times i have wanted to find an rpm or see what versions of an rpm are available. When theyre stored as files, all i need to do is “locate blah | grep rpm” and i can see exactly what is there. Then i can scp the file directly to a client, in about 2 seconds. Now i can’t do that.
Further, the other day I synced centos 7 repos, and i had pulp using 36 GB. I ended up deleting those repos because i wanted to structure the product hierarchy differently, and after deleting the products in foreman, they still used 36 GB. I then tried a foreman-rake command to delete orphaned content, and it did nothing, still 36 GB. Now what do I do? Do i have to query the API to try to work out what foreman has lost track of? If the rpms were stored as rpms, i could just delete them, and tell foreman to clean itself up. Now what do I do, if the orphan cleanup is failing to free space?
Bah. I just don’t like decisions that make products harder to use and harder to debug, when things go wrong, because things ALWAYS go wrong. Or things seem to go wrong, and you need to be able to check and verify things, in order to work out that no, things have not gone wrong.
So, developers, please, for God’s sake, please, just bless your users with the gift of logfiles, and a generally transparently-operating product. Not an opaque product that is just a broken black box when it fails. Logfiles are good for everyone.