Description of problem: Trying to delete a host group, it (somewhat silently) fails. Viewing dynflow, user is told that the CV cannot be deleted because a host group is dependent on the CV. However, checking the CV, there is zero reference to said CV. Version-Release number of selected component (if applicable): Satellite-6.1.0-RHEL-7-20150320.1 How reproducible: Unsure.... jsherrill has an idea. Steps to Reproduce: 1. Go through content cycle for RHEL6 (sync, cv pub/promote, ak, etc.) 2. Register RHEL6 system (maybe?) 3. Repeat above for RHEL7 4. Create a hostgroupfor RHEL7 that specifically points to RHEL7 content 5. Attempt to remove CV for RHEL6 6. View Dynflow to see failure (nothing really shows up in CV UI) Actual results: Failure to remove CV listed in dynflow (see forthcoming attached trace from dynflow) Expected results: Can remove Things are not misassociated! Additional info: jsherrill probably has more reliable steps
Created attachment 1005984 [details] dynflow trace
So the key to reproducing here involves making sure you have a lifecycle environment and content view with the same ID. So! Steps to reproduce: 1) On a freshly provisioned Satellite, Create a new Lifecycle Environment (with ID 2) 2) Create and publish ContentViewA (with ID 2) 3) Create and Publish ContentViewB (with ID 3) 4) Create a hostgroup and associate it to the created Lifecycle Environment With ID 2, and the ContentViewB with ID 3 5) Attempt to Delete the Content View with ID 2 It is not associated to the hostgroup and thus should delete fine, however it will fail.
Created redmine issue http://projects.theforeman.org/issues/9902 from this bug
Upstream bug assigned to jsherril
Should be fixed when https://github.com/Katello/katello/pull/5143/files gets merged.
VERIFIED : # rpm -qa | grep foreman foreman-libvirt-1.7.2.17-1.el6_6sat.noarch ruby193-rubygem-foreman_bootdisk-4.0.2.10-1.el6_6sat.noarch ruby193-rubygem-foreman_hooks-0.3.7-2.el6_6sat.noarch rubygem-hammer_cli_foreman_tasks-0.0.3.3-1.el6_6sat.noarch rubygem-hammer_cli_foreman_bootdisk-0.1.2.5-1.el6_6sat.noarch foreman-postgresql-1.7.2.17-1.el6_6sat.noarch foreman-debug-1.7.2.17-1.el6_6sat.noarch foreman-1.7.2.17-1.el6_6sat.noarch foreman-ovirt-1.7.2.17-1.el6_6sat.noarch ruby193-rubygem-foreman-tasks-0.6.12.3-1.el6_6sat.noarch foreman-proxy-1.7.2.4-1.el6_6sat.noarch qe-sat6-rhel66.usersys.redhat.com-foreman-client-1.0-1.noarch qe-sat6-rhel66.usersys.redhat.com-foreman-proxy-client-1.0-1.noarch foreman-selinux-1.7.2.13-1.el6_6sat.noarch rubygem-hammer_cli_foreman-0.1.4.9-1.el6_6sat.noarch foreman-compute-1.7.2.17-1.el6_6sat.noarch foreman-vmware-1.7.2.17-1.el6_6sat.noarch ruby193-rubygem-foreman-redhat_access-0.1.0-1.el6_6sat.noarch ruby193-rubygem-foreman_gutterball-0.0.1.9-1.el6_6sat.noarch qe-sat6-rhel66.usersys.redhat.com-foreman-proxy-1.0-2.noarch ruby193-rubygem-foreman_docker-1.2.0.9-1.el6_6sat.noarch rubygem-hammer_cli_foreman_discovery-0.0.1.7-1.el6_6sat.noarch foreman-gce-1.7.2.17-1.el6_6sat.noarch ruby193-rubygem-foreman_discovery-2.0.0.9-1.el6_6sat.noarch steps: 1) On a freshly provisioned Satellite, Create a new Lifecycle Environment (with ID 2) 2) Create and publish ContentViewA (with ID 2) 3) Create and Publish ContentViewB (with ID 3) 4) Create a hostgroup and associate it to the created Lifecycle Environment With ID 2, and the ContentViewB with ID 3 5) Attempt to Delete the Content View with ID 2 6) Delete works fine for content View with ID 2
This bug is slated to be released with Satellite 6.1.
This bug was fixed in version 6.1.1 of Satellite which was released on 12 August, 2015.