Problem:
Trying to push custom files into File Type Repo and publish them in a CV through my Lifecycle Environments. Appears that File Type repos ignore the LEs and just publish through Library.
Expected outcome:
Expected all repo types to follow publish/promotion workflows to allow content to be managed through lifecycle environments.
Foreman and Proxy versions:
Foreman 3.1
Katello 4.3
Foreman and Proxy plugin versions:
Distribution and version:
CentOS 8 Stream
Other relevant data:
Am I just barking up the wrong tree here? I know I can add the File Type Repository to a Content View, then publish and promote that Content View. But I cannot seem to be able to access the content other than via the “Published At:” URL listed in the hammer repository info --id=495 output.
After quite some fooling around with the File Type Repo URL - copying the bulk of the URL which was present in the /etc/yum.repos.d/katello.repo file - I realised that the File Type repo has /isos/ in it’s URL rather than /repo/.
I couldn’t actually find any documentation of putting File Type repos through Content Views and publishing/promoting through Lifecycle environments. Is there something I missed?
I don’t know the full background of this, but some small part of it (hopefully others can fill in the gaps):
In Pulp 2 times each Pulp content type published under a different path, and for pulp_file this included /isos/ (since that was the main use case for file repos that the designers had in mind at the time). In Pulp 3 (which you have with Katello 4.3) I believe the whole path is controlled by Katello, but I think it would have been kept the same as in the Pulp 2 days for continuity. So I think, the /isos/ part of the path is by design. I could be wrong though, and I don’t know if there are any docs for “File repo CV workflows”.
Yes - “undocumented” is unfair. But there is no mention of using the File Repos in Content Views. The example given doesn’t show any hint of the repo being used in a Content View. This is different from Yum Repos being used in Content Views, as clients are given the URLs to access Yum Repos in the .repo file, so the user never has to calculate the right URL.
Our use case is to provide versioned tarballs to clients via CV, so the use-case was throwing us off a little.
It might benefit users if there was some explanation of how to calculate the URL for Content View versions of File repos. Something like:
Find the repo ID in the Lifecycle you are looking for by:
# hammer repository list --organization-id 1 --content-type file --lifecycle-environment ENG
---|----------|---------|--------------|----
ID | NAME | PRODUCT | CONTENT TYPE | URL
---|----------|---------|--------------|----
35 | filerepo | Core | file |
---|----------|---------|--------------|----
then take the ID and get the detailed info on that repo with:
# hammer repository info --id 35
Id: 35
Name: filerepo
Label: filerepo
Description:
Organisation: Innes
Red Hat Repository: no
Content Type: file
Mirror on Sync: yes
Url:
Publish Via HTTP: yes
Published At: https://katello.innes.net/pulp/content/Innes/ENG/rhel8withfile/custom/Core/filerepo/
Relative Path: Innes/ENG/rhel8withfile/custom/Core/filerepo
Download Policy:
HTTP Proxy:
HTTP Proxy Policy: none
Product:
Id: 293
Name: Core
GPG Key:
Sync:
Status: Not Synced
Created: 2022/02/21 16:11:27
Updated: 2022/02/21 16:15:46
Content Counts:
Files: 1
Is this too much? Not enough? Unnecessary? I realise ours may potentially be an edge case scenario, but some mention of how to use the File type Repo once it’s published/promoted in a CV/CCV would help I think.