Closed rhjhunt closed 4 years ago
I would say that is expected, as you shouldn't be providing a basearch
for that repo, there is an example showing how to enable that RHEL 8 repo in the ansible-doc
output...
I saw the example and initially followed it, technically it works. My only question, in reference to the screenshot attached, is why are the repos under noarch
? If you add the repos through the WebUI of Satellite they are placed under x86_64
, I would expect the module to add the repos in the same fashion.
Hey @rhjhunt, I'm currently looking into this issue and the example Sean posted seems to work for me, both on Satellite 6.5 (tfm-rubygem-katello-3.10.0.58-1.el7sat.noarch) and on a recent Katello 3.14 (RC2).
However, one thing that strikes me odd is your screenshot. That's the old repositories page from Satellite 6.4. On 6.5 I see the following:
Is the screenshot from 6.4? If it is: I think EL8 is not supported on Sat 6.4/Katello 3.7, so I'd lean to close this as "not a bug". If it's on Satellite 6.5/Katello 3.10, then we need to dig further.
@evgeni that was from a Satellite 6.5 system, I don't have it around anymore but I do have the playbook so I can great another one. I'm tempted to try both Satellite 6.6 and 6.5 to see if the issue still exists. Let me reproduce and I'll report back.
Ooooh, that's the "sync status" page, not the "repositories" page, I was blind :tired_face:
Okay, so when looking at the right page, I indeed see noarch when we enable via Ansible, and x86_64 when via UI. Same also on Katello 3.14 (latest upstream).
Okay, so looking at the requests generated:
us:
2019-12-20T12:33:18 [I|app|7e15203d] Started PUT "/katello/api/products/14/repository_sets/7416/enable" for 192.168.122.1 at 2019-12-20 12:33:18 +0000
2019-12-20T12:33:18 [I|app|7e15203d] Processing by Katello::Api::V2::RepositorySetsController#enable as JSON
2019-12-20T12:33:18 [I|app|7e15203d] Parameters: {"releasever"=>"8", "organization_id"=>1, "api_version"=>"v2", "product_id"=>"14", "id"=>"7416", "repository_set"=>{"releasever"=>"8", "organization_id"=>1}}
WebUI:
2019-12-20T12:45:57 [I|app|524d800f] Started PUT "/katello/api/v2/products/14/repository_sets/7416/enable" for 192.168.122.1 at 2019-12-20 12:45:57 +0000
2019-12-20T12:45:58 [I|app|524d800f] Processing by Katello::Api::V2::RepositorySetsController#enable as JSON
2019-12-20T12:45:58 [I|app|524d800f] Parameters: {"id"=>"7416", "product_id"=>"14", "basearch"=>"x86_64", "releasever"=>"8", "api_version"=>"v2", "repository_set"=>{"id"=>"7416", "product_id"=>"14", "basearch"=>"x86_64", "releasever"=>"8"}}
It seems the UI sends basearch, even if it's not part of the substitutions of the repository.
@rhjhunt great news, I could repro and have a fix in #670! :)
@rhjhunt bad news, I think I've opened a can of worms inside Katello with this, see https://projects.theforeman.org/issues/28555 and https://projects.theforeman.org/issues/28644. I'd prefer not to fix this before we understand the Katello behavior better.
basearch
gets pruned from repos that don't have that substitution in katello 3.16, see https://projects.theforeman.org/issues/28644
the "noarch" UI issue is unsolved yet (https://projects.theforeman.org/issues/28555), but it seems like the current behaviour is mostly correct.
I am thus closing this issue as "notabug"
SUMMARY
When using the module katello_repository_set to enable a RHEL 8 repository if basearch is set to x86_64 no action is performed. If basearch isn't defined the repository is enabled but placed under
noarch
.ISSUE TYPE
ANSIBLE VERSION
KATELLO/FOREMAN VERSION
NAILGUN VERSION
I so far have done
pip install nailgun
.STEPS TO REPRODUCE
I have a simple task to enable a repository set:
EXPECTED RESULTS
I expect that the repository set will be enabled.
ACTUAL RESULTS
The repository set was not enabled, the task was skipped with no action to perform.