Hide Forgot
Docker tags whitelist (called "Container Image Tags Filter" in hammer, "Limit Sync Tags" in web UI) field is set in any repository edited through web UI. It seems that web UI always sets and sends that field and nothing in backend filters it out for non-docker repositories. So far I wasn't able to discover any negative impact of that field set for non-docker repositories. Version: Satellite 6.5 snap 3 pulp-server-2.17.1-1.el7sat.noarch katello-3.9.0-0.11.rc2.el7sat.noarch foreman-1.20.0-0.17.RC2.el7sat.noarch satellite-6.5.0-3.beta.el7sat.noarch Steps to reproduce: 1. Create new product 2. Create new repository of type different than docker 3. Verify that docker_tags_whitelist key is not set for new repository (in hammer you should not see "Container Image Tags Filter", in API "docker_tags_whitelist" should be `null`) 4. Edit this repository using web UI (e.g. change name) 5. Repeat step 3 Actual results: `hammer repository info --id <id>` will contain "Container Image Tags Filter" line `curl -u admin:PASS -k https://localhost/katello/api/repositories/<id>` will return `"docker_tags_whitelist": []` Expected results: docker tags whitelist is not changed - it is still equal to `null` in API, line is not present in hammer Additional info: Changing repository using hammer does not affect docker_tags_whitelist field
Connecting redmine issue https://projects.theforeman.org/issues/25688 from this bug
Created redmine issue https://projects.theforeman.org/issues/25980 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25980 has been resolved.
After changing non-docker repository through web UI, hammer does not display "Container Image Tags Filter". Docker tags whitelist value `[]` is send, but it doesn't have any impact on UI or application logic. Version: Satellite 6.5 snap 18 tfm-rubygem-katello-3.10.0.24-1.el7sat.noarch foreman-1.20.1.10-1.el7sat.noarch pulp-server-2.18.0-0.1.rc.el7sat.noarch satellite-6.5.0-6.beta.el7sat.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:1222