Bug 1108226 - [RFE] Use automember for hosts after the host is added
Summary: [RFE] Use automember for hosts after the host is added
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Lenka Doudova
Depends On:
Blocks: 1370127
TreeView+ depends on / blocked
Reported: 2014-06-11 14:58 UTC by Martin Kosek
Modified: 2016-08-25 11:36 UTC (History)
2 users (show)

Fixed In Version: ipa-4.0.3-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1370127 (view as bug list)
Last Closed: 2015-03-05 10:11:55 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0442 0 normal SHIPPED_LIVE Moderate: ipa security, bug fix, and enhancement update 2015-03-05 14:50:39 UTC

Description Martin Kosek 2014-06-11 14:58:01 UTC
This bug is created as a clone of upstream ticket:

It became apparent that there are some cases when the purpose thus and proper system placing into the host groups is not known in advance. Consider the following scenario:
 1. There is an existing system not integrated with IPA, Spacewalk or other management software but running some application.
 2. The system should be inspected, classified and the right configuration and policy should be applied.
 3. The first step is to enrol it into IPA so that management software can SSH into the system and collect facts and stats. At this point the host needs to be created in IPA but the type of the host is yet to be determined.
 4. Once the system is enrolled the management software would connect, collect facts and determine the class or type of the system.
 5. The management software then should be able to issue command that would trigger autoplacement plugin for already existing host.

Comment 1 Martin Kosek 2014-06-11 15:23:31 UTC
This request is already fixed in upstream FreeIPA project. Please refer to the linked ticket for additional details and related commits.

Comment 3 Lenka Doudova 2015-01-28 14:07:52 UTC
In UI, tests were performed:

1. Automember for separate entries:
     - added two hostgroups
     - added an automember rule to both hostgroups - class=<str>
     - added two hosts without specifying a class
     - checked that hosts are not included in any hostgroup
     - specified a class for both hosts (one corresponding to one host group, the other one to the second host group)
     - checked that hosts were not yet added to the corresponding hostgroups
     - open one host, click Action > Rebuild auto membership > Confirm
     - checked that host is now assigned to the corresponding hostgroup, other hosts are not effected (the change is visible only after refreshing the UI)

2. Automember for all entries:
     - created two new hosts without specifying class
     - specified a class for both hosts (corresponding to hostgroups from 1)
     - in Hosts dialog: Actions > Rebuild auto membership
     - checked that both new hosts were assigned to corresponding hostgroup

3. Automember for selected entries:
     - repeated test No. 2, only this time only one of the new entries was selected, thus automember was performed only for the selected entry

In case a host was already included in a hostgroup and later the class attribute of that entry was deleted/changed and automember was rebuilt, the entry still belonged to original hostgroup after performing the rebuilt. I'm not sure if that's correct behavior.

Comment 5 errata-xmlrpc 2015-03-05 10:11:55 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.


Note You need to log in before you can comment on or make changes to this bug.