Bug 1110360

Summary: Can't search for host with class inherited from config group
Product: Red Hat Satellite Reporter: Bryan Kearney <bkearney>
Component: ProvisioningAssignee: jmagen <jmagen>
Status: CLOSED ERRATA QA Contact: Tazim Kolhar <tkolhar>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.0.3CC: bbuckingham, cwelton, dcleal, jmagen, jmontleo, stbenjam, tkolhar
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/5848
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-12 05:09:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1135919    
Bug Blocks:    

Description Bryan Kearney 2014-06-17 13:44:54 UTC
Hi,

I updated the foreman to 1.5 and I am making some tests with configs group.

Add a config group to a host or hostgroup is working, but 
1/ I am unable to list hosts where puppet classes are inherited from config group. 
2/ I am unable to list hosts where puppet classes are inherited from a config group included in the host group.

Let's say, I have a host named "myserv" with:
- a class (rule100) added for this host 
- a class (rule1) inherited from hostgroup
- a class (rule80) inherited from a config group which was added only for this host.
- a class (rule21) inherited from a config group which was added in the host group.

If I go to foreman web interface -> hosts -> all hosts. Then if I want to filter by class typing :
- "class=rule100" on the filter field, I can find my host. The same with a class (rule1) inherited from group. 
-  class=rule21, I can't find my host (class inherited from a config group which was added in the host group). The same with class=rule80 (class inherited from a config group which was added only for this host).

I am using admin account to be sure I have full rights. Using debug mode, I can see that there is no SQL request looking on config_group_classes and config_group tables while I am doing my research.

Regards,

Elodie

Comment 1 Bryan Kearney 2014-06-17 13:44:56 UTC
Created from redmine issue http://projects.theforeman.org/issues/5848

Comment 2 Bryan Kearney 2014-06-17 13:45:01 UTC
Upstream bug assigned to jmagen

Comment 4 Bryan Kearney 2014-06-17 14:05:32 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/5848 has been closed

Comment 7 Tazim Kolhar 2014-08-27 12:29:43 UTC
please provide verification steps

Comment 8 Stephen Benjamin 2014-09-01 07:40:19 UTC
Verification steps
1. Create a config group and assign a puppet class to it
2. Create a host group, and add the config group to it
3. Create 3 hosts:
    1. one with the config group from step 1
    2. one with the host group from step 2
    3. one with neither
4. Search for a puppet class in the Hosts page 'class = <class>' where <class> is the puppetclass you added
5. You should see only hosts 1 and 2

Comment 11 Tazim Kolhar 2014-09-01 09:12:51 UTC
here, as discussed since dev-testing is failing will keep a track of
https://bugzilla.redhat.com/show_bug.cgi?id=1135919  post which
will verify the BZ as per the verification steps given

Comment 12 jmagen@redhat.com 2014-09-01 11:16:39 UTC
Merged f06b276b93f9ff47ca66174c606fee6fc2c64321 in upstream develop branch for
http://projects.theforeman.org/issues/7035

It should work when patch is cherry-picked downstream

Comment 15 Tazim Kolhar 2015-03-11 08:11:47 UTC
VERIFIED:

# rpm -qa | grep  foreman
foreman-compute-1.7.2.9-1.el6_6sat.noarch
ruby193-rubygem-foreman_discovery-2.0.0.6-1.el6_6sat.noarch
rubygem-hammer_cli_foreman_discovery-0.0.1.2-1.el6_6sat.noarch
foreman-debug-1.7.2.9-1.el6_6sat.noarch
rubygem-hammer_cli_foreman_bootdisk-0.1.2.5-1.el6_6sat.noarch
foreman-selinux-1.7.2.8-1.el6_6sat.noarch
foreman-ovirt-1.7.2.9-1.el6_6sat.noarch
foreman-libvirt-1.7.2.9-1.el6_6sat.noarch
ruby193-rubygem-foreman-redhat_access-0.0.9-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
rubygem-hammer_cli_foreman-0.1.4.6-1.el6_6sat.noarch
foreman-vmware-1.7.2.9-1.el6_6sat.noarch
ruby193-rubygem-foreman_bootdisk-4.0.2.8-1.el6_6sat.noarch
foreman-proxy-1.7.2.3-1.el6_6sat.noarch
qe-sat6-rhel66.usersys.redhat.com-foreman-proxy-1.0-2.noarch
rubygem-hammer_cli_foreman_tasks-0.0.3.3-1.el6_6sat.noarch
foreman-1.7.2.9-1.el6_6sat.noarch
foreman-gce-1.7.2.9-1.el6_6sat.noarch
ruby193-rubygem-foreman_hooks-0.3.7-2.el6_6sat.noarch
ruby193-rubygem-foreman-tasks-0.6.12.1-1.el6_6sat.noarch
ruby193-rubygem-foreman_gutterball-0.0.1.9-1.el6_6sat.noarch
foreman-postgresql-1.7.2.9-1.el6_6sat.noarch
ruby193-rubygem-foreman_abrt-0.0.5-2.el6_6sat.noarch
ruby193-rubygem-foreman_docker-1.2.0.3-1.el6_6sat.noarch

host inherited from class config groups is visible

Comment 16 Bryan Kearney 2015-08-11 13:25:31 UTC
This bug is slated to be released with Satellite 6.1.

Comment 17 errata-xmlrpc 2015-08-12 05:09:28 UTC
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-2015:1592