Common server properties for Inventory and Promising service groups

Use the properties such as group name, replica count, resources, and other server properties when configuring the IVServiceGroup and PromisingServiceGroup.

The following table explains the common properties for servers:

Property	Default value	Value type	Required	Description
`active`	true	boolean	No	This flag is set to `true` by default to activate a server or a group of servers. To deactivate, set it to `false`. For more information about deactivating, see Deactivating an active server.
`affinityAndTolerations`		string	No	Use the name of the `affinityAndTolerations` that is defined in the SIPEnvironment. By default, the `affinityAndTolerations` defined in the server takes precedence over the `affinityAndTolerations` that is defined in the individual service group.
`horizontalPodAutoscaler`		string	No	Specify the name of the pre-defined Horizontal Pod Autoscaler that is to be used. For more information, see horizontalPodAutoscalers parameter.
`image.tag`		string	No	Specify this property to define the image tag for the individual server. If it is not set, the tag that is defined in the service group or global configuration in SIPEnvironment is used. This enables precise control over the image version that is used by each server instance.
`image.pullPolicy`		string	No	Specify this property to define the image pull policy for the individual server. If it is not set, the policy defined in the service group or global configuration in SIPEnvironment is used. This controls the image pull behavior for the server instance.
`logLevel`	`INFO`	integer	No	Specify this property to override the log level at the individual server level. Available options are `OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL`. If not set at the individual server level, the log level that is defined at the service group level is used. If the service group log level is also not defined, then the global configuration in SIPEnvironment is used. If none of these is set, the default log level is `INFO`. This allows customized control of logging for each server instance.
`groupName`	Group name is pre-defined for each server.	string	Yes	It is the group name of the servers (app server, backend server or logstash server) that are included in the service. You can modify the group name as required. In Kubernetes, the character limit of label values is 63, which often cause deployment errors with long resource names. To avoid errors, you can use group name to identify deployments, allowing flexible and organized deployment management. For more information, see Using group names to avoid errors with long resource names.
`pod.podAnnotations`		object	No	Specify any additional annotations for pod or deployment as a key-value pair.
`pod.podLabels`		object	No	Specify any additional labels for pod or deployment as a key-value pair. Remember: Do not override the following three labels, as they are internally used by the Operator. `app` `type` `internal.sip.ibm.com/apps`
`names`		array	Yes	It is the list of the names of the servers that are included in the service. For Promising, this property is applicable for a single app server only. For backend servers, it is the list of the servers with the number of threads.
`replicaCount`	For dev: 1 For production: 2	integer	No	Specify the number of replicas for the servers.
`resources`	For dev: Limits: CPU= 1 Memory= 1536Mi Requests: CPU= 100m Memory= 1Gi For production, specify limits and requests for CPU and memory, based on your cluster configuration.		No	Specify the CPU and memory resource requests and limits for servers.
`property.envVars`		string	No	Use the name of envVars from attribute `serverProperties.envVars[].groupName` or `serverProperties.envVars[].derivatives[].groupName`.
`property.jvmArgs`		string	No	Use the name of jvmArgs from attribute `serverProperties.jvmArgs[].groupName` or `serverProperties.jvmArgs[].derivatives[].groupName`.
`topology`		array	No	Specify the names of the Topology Spread Constraints that are to be used for the server. For example, `topology: [constraint1, constraint2]`. The topology defined in the servers or in the jobs takes precedence over the one defined in the individual service groups. For more information, see Examples to call Topology Spread Constraints from servers.

Properties specific to jobs

Property	Default value	Value type	Required	Description
`name`		array	Yes	It is the list of names of the jobs that are included in the service.
`affinityAndTolerations`		string	No	Use the name of the `affinityAndTolerations` that is defined in the SIPEnvironment. By default, the `affinityAndTolerations` defined in the server takes precedence over the `affinityAndTolerations` that is defined in the individual service group.
`logLevel`	`INFO`	integer	No	Specify this property to override the log level at the individual server level. Available options are `OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL`. If not set at the individual server level, the log level that is defined at the service group level is used. If the service group log level is also not defined, then the global configuration in SIPEnvironment is used. If none of these is set, the default log level is `INFO`. This allows customized control of logging for each server instance.
`jobBackoffLimit`	4	integer	No	Specify the number of retries before marking the job as failed after consecutive pod failures.
`pod.podAnnotations`		object	No	Specify any additional annotations for pod or deployment as a key-value pair.
`pod.podLabels`		object	No	Specify any additional labels for pod or deployment as a key-value pair. Remember: Do not override the following three labels, as they are internally used by the Operator. `app` `type` `internal.sip.ibm.com/apps`
`resources`	For dev: Limits: CPU= 1 Memory= 1536Mi Requests: CPU= 100m Memory= 1Gi For production, specify limits and requests for CPU and memory, based on your cluster configuration.		No	Specify the CPU and memory resource requests and limits for servers.
`topology`		array	No	Specify the names of the Topology Spread Constraints that are to be used for the server. For example, `topology: [constraint1, constraint2]`. The topology defined in the servers or in the jobs takes precedence over the one defined in the individual service groups. For more information, see Examples to call Topology Spread Constraints from servers.

Deactivating an active server

Deactivate an active server by changing the active flag to false, so that the deployments associated with that server are deleted. If you group the servers, use the active flag to deactivate the complete group.

Using group names to avoid errors with long resource names

Instead of directly using long deployment names in labels or selectors, for example, metadata.labels, spec.selector.matchLabels, which may exceed the 63-character limit, assign a concise group name to represent the deployment. This approach enables simpler label management and organizes specific deployment configurations within the group.

Example:

promisingServiceGroup:
  - active: true
    groupName: <deployment-name>
    names:
      - "iv-supply-breakup-snapshot-source-stream-flatten:4"
    replicaCount: 4