Consumer properties

Property	Description
Name	A unique name of a department or project in your structure.
Roles	List of roles that are relative to this consumer and all consumers beneath it. Depending on the permissions associated with the roles, a user may modify any property, assign resources, and control hosts. Role View permission is required to see the list of roles.
Users	List of user accounts that are relative to this consumer. User View permission is required to see the list of users.
OS user account	The operating system user account under which workload runs. All workload for the consumer runs under the same account, no matter which user submitted workload units. On Linux® hosts, the $SOAM_HOME/deploy directory’s group access permissions is set to 7 (rwx). All execution (OS) users of consumers must belong to the deploy directory owner group. The deploy directory is created and owned by the cluster administrator OS user account (by default, `egoadmin`). Additionally, ensure that you include all consumer OS user accounts under the same group as the cluster administrator OS user account; otherwise, you may encounter issues with writable permissions to SOAM work directories, such as these: $SOAM_HOME/datamanager $SOAM_HOME/history $SOAM_HOME/jouraling $SOAM_HOME/paging Note: As of IBM® Spectrum Symphony 7.2.1, you can allow SSM to use the same cluster administrator permissions that SD uses by setting a cluster-wide environment variable (SD_SSM_RUN_AS_CLUSTER_ADMIN) to TRUE in the service definition file (sd.xml). This way, SSM processes run as the cluster administrator, rather than as the execution user. For details about SD_SSM_RUN_AS_CLUSTER_ADMIN, see Session director environment variables. If the consumer runs workload units on a Windows host, include the domain name as shown: `domain_name\user_name` If the consumer runs workload units on a Linux host, EGO can automatically strip the domain name from the user name. For example, if you configure the account as `mydomain\user2`, it is interpreted as `mydomain\user2` on Windows but as `user2` on Linux. Every new Windows execution user account needs to have the password configured with egosh ego execpasswd. The egoadmin account is already configured. Any activity started through egosh uses the same execution account as configured for the leaf consumer it runs on. The file ConsumerTrees.xml contains execution user account information for each registered consumer. Note: Once an execution user account has been configured for a consumer, it cannot be changed. If the user account is not correct, you must delete the consumer and create a new one. Before deleting a consumer, unregister all applications associated with it.
Allowed execution user list or execution group list	The allowed execution user or group list for the consumer. This is a comma-separated list of OS or LDAP users or groups that are allowed to be execution users. The OS user account of the current consumer must either be in the allowed execution user list or be a member of a group in the allowed execution group list, except when Any user can be the OS execution user is selected. The allowed execution user list of a child consumer must either be a subset of the allowed execution user list of the parent consumer or be members of a group in the allowed execution group list of the parent consumer. The allowed execution group list of the child consumer must be a subset of the allowed execution group list of the parent consumer. For the parent consumer, if Any user can be the OS execution user is selected, any user can be the OS user account for this consumer. For a child consumer, if Inherit the user list and group list from parent consumer is selected, the child consumer will automatically inherit the same user list and group list from its parent consumer. For the users and groups configured in the allowed execution user list or execution group list, only the PAM, AD, and default security plug-ins validate if the specified users and groups exist when creating and modifying consumers or starting EGO activities. For the default plug-in, the parameter ENABLE_BI_AUTH (which is only supported by Linux) must be set in $EGO_CONFDIR/ego.conf; for example: `EGO_SEC_PLUGIN=sec_ego_default EGO_SEC_CONF=/opt/ego/kernel/conf,time-to-live_duration,ENABLE_BI_AUTH` Note that you can optionally specify a time-to-live duration, in minutes, to be used for the authentication token sent from client to server. If not specified, the system uses the default time-to-live duration of 600 minutes, which is 10 hours. To use the default time-to-live duration, do not provide a value, but keep the commas (and no extra spaces), to separate the configuration options, as such: `EGO_SEC_PLUGIN=sec_ego_default EGO_SEC_CONF=/opt/ego/kernel/conf,,ENABLE_BI_AUTH`
Resource groups	A collection of hosts. You can create resource groups based on similar qualities or by machine names. Only those resource groups assigned to this consumer by its parent consumer are available for assignment.
Reclaim	Reclaim applies to consumers that are borrowing resources. If a client is running workload units on a borrowed resource, you can impose a delay (grace period) so that these units can run uninterrupted before the resource gets returned (reclaimed). Alternately, you can choose to immediately interrupt workload units running on a borrowed resource when it is reclaimed by setting the grace period to 0. When a grace period is blank or not configured, it defaults to 0 seconds.
Slot underallocation SNMP event	SNMP trigger settings that apply to consumers with unsatisfied demand. If the configured minimum number of slots is not allocated to the consumer within a defined duration, an SNMP event is triggered. The minimum number of slots includes all slots that the consumer can get from all configured resource groups, such as ManagementHosts, ComputeHosts, and so on.