Bug 1108226

Summary:	[RFE] Use automember for hosts after the host is added
Product:	Red Hat Enterprise Linux 7	Reporter:	Martin Kosek <mkosek>
Component:	ipa	Assignee:	Martin Kosek <mkosek>
Status:	CLOSED ERRATA	QA Contact:	Lenka Doudova <lryznaro>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.1	CC:	lryznaro, rcritten
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ipa-4.0.3-1.el7	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1370127 (view as bug list)		Environment:
Last Closed:	2015-03-05 10:11:55 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:
Bug Blocks:	1370127

Description Martin Kosek 2014-06-11 14:58:01 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/3752

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

Note:
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.

https://rhn.redhat.com/errata/RHSA-2015-0442.html