Description of problem: If one tries changing Puppet environment of a host to an environment which doesn't contain a puppet module which is assigned to the host, the operation will silently fail without any explanation in the UI. In the production.log, the following line can be seen: Failed to save: Puppetclasses puppet_dev does not belong to the KT_acme_it_Prototype_ACME_IT_Sample_Service_13 environment Version-Release number of selected component (if applicable): satellite 6.0.6 Steps to Reproduce: 1. Create a host with some puppet class assigned and a smart-parameter set 2. Edit the host and change to a Puppet Environment where said puppet class isn't present 3. Press Submit 4. Note how you are taken back to the "edit host" screen without any explanation
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Will it be acceptable to remove all the puppet classes in case of environment change? This behavior already exists in hostgroups.
Considering removing classes also implies removing SmartClass parameters, I would prefer a more conservative approach asking "are you sure?" Or maybe just failing with an appropriate error message. Also, I don't expect any classes to be removed if they are present in the new environment either. Moving a machine from dev to prod might be a valid use-case
Created redmine issue http://projects.theforeman.org/issues/10738 from this bug
Upstream bug assigned to sshtein
Moving to POST since upstream bug http://projects.theforeman.org/issues/10738 has been closed ------------- Shimon Shtein Applied in changeset commit:fa229d321ada9913d98c9ada103678ab73ff222e.
VERIFIED: # rpm -qa | grep foreman hp-dl360g7-01.lab.eng.brq.redhat.com-foreman-proxy-1.0-1.noarch foreman-release-1.11.0-0.develop.201511161350git860ef06.el7.noarch foreman-vmware-1.11.0-0.develop.201511161350git860ef06.el7.noarch foreman-debug-1.11.0-0.develop.201511161350git860ef06.el7.noarch foreman-libvirt-1.11.0-0.develop.201511161350git860ef06.el7.noarch foreman-selinux-1.11.0-0.develop.201510071426git6234447.el7.noarch tfm-rubygem-foreman_hooks-0.3.9-1.el7.noarch tfm-rubygem-hammer_cli_foreman_tasks-0.0.8-1.el7.noarch tfm-rubygem-foreman_gutterball-0.0.1-3.el7.noarch foreman-postgresql-1.11.0-0.develop.201511161350git860ef06.el7.noarch hp-dl360g7-01.lab.eng.brq.redhat.com-foreman-proxy-client-1.0-1.noarch tfm-rubygem-foreman_discovery-4.1.2-1.fm1_11.el7.noarch foreman-1.11.0-0.develop.201511161350git860ef06.el7.noarch foreman-ovirt-1.11.0-0.develop.201511161350git860ef06.el7.noarch tfm-rubygem-hammer_cli_foreman_bootdisk-0.1.3-3.el7.noarch foreman-proxy-1.11.0-0.develop.201511161424gitf24be74.el7.noarch foreman-compute-1.11.0-0.develop.201511161350git860ef06.el7.noarch tfm-rubygem-hammer_cli_foreman_docker-0.0.3-4.el7.noarch hp-dl360g7-01.lab.eng.brq.redhat.com-foreman-client-1.0-1.noarch tfm-rubygem-foreman_bootdisk-6.0.0-2.fm1_10.el7.noarch tfm-rubygem-hammer_cli_foreman-0.4.0-1.201511111650gitdda13df.el7.noarch foreman-gce-1.11.0-0.develop.201511161350git860ef06.el7.noarch foreman-release-scl-1-1.el7.x86_64 tfm-rubygem-foreman_docker-1.4.1-2.fm1_10.el7.noarch tfm-rubygem-foreman-tasks-0.7.6-1.fm1_10.el7.noarch steps: 1. Create a host with some puppet class assigned and a smart-parameter set 2. Edit the host and change to a Puppet Environment where said puppet class isn't present 3. Press Submit
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/RHBA-2016:1500