IVServiceGroup custom resource parameters
Set up your own IVServiceGroup custom resource by configuring the parameters
in a YAML, as required.
The following tables explain the metadata and specifications for
IVServiceGroupNote: By default, the
image specifications that are defined under
IVServiceGroup takes precedence over the global image specifications
that are defined in the SIPEnvironment. The image parameters appear by
default, hence, to override the default image parameters, update the parameters as
required.| Property | Default value | Value type | Required | Description |
|---|---|---|---|---|
name |
string | Yes | Specify the environment to which you want to deploy your service group. You can deploy
service groups in the following three modes:
|
|
namespace |
string | Yes | Specify the namespace where the IVServiceGroup will be
created. |
| Property | Default value | Value type | Required | Description |
|---|---|---|---|---|
active |
false |
boolean | Yes | Specify the active property to true to activate the service
group for Inventory Visibility and create resources and deployments in the cluster. When
you create a service group independently, you must activate it manually. Important: You
can create multiple service groups but can activate only one at a time in the namespace. Deactivate
the active service group to activate a new service group. For more information, see Deactivating an active service group.
|
affinityAndTolerations |
string | No | Use the name of the affinityAndTolerations that is defined in the SIPEnvironment. |
|
horizontalPodAutoscaler |
string | No | Specify the name of the pre-defined Horizontal Pod Autoscaler that is to be used. For more information, see horizontalPodAutoscalers parameter. | |
logLevel |
INFO |
string | No | Specify the logging level for Inventory Visibility service group. Available
options are OFF, FATAL, ERROR, WARN, INFO, DEBUG,TRACE, ALL.If the logging level
at the individual server level is not defined, the log level that is defined at Inventory Visibility 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 |
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.
|
|
defaultReplicas |
1 | integer | Yes | Specify the number of replicas for the IVServiceGroup. |
defaultresources |
For dev: Limits: CPU= 1 Memory= 1536Mi Requests: CPU= 100m Memory= 1Gi |
object | Yes | Specify the CPU and memory resource requests and limits for the IVServiceGroup. |
image |
object | No | Specifying image properties are optional. For more information, see a list of IVServiceGroup image properties. |
|
image.imagePullSecrets |
array | No | References to secrets in the same namespace for pulling the images. It can be referred as
name-value pair. |
|
appServers |
<List of auto-populated servers> | object | A list of app servers is automatically populated based on the environment (dev or production) that you have specified in your custom resource. For dev all the servers are grouped together and for production, each server has its own group. For a list of common properties for application servers, see Common server properties for Inventory and Promising service groups. | |
backendServers |
<List of auto-populated servers> | object | A list of backend servers is automatically populated based on the environment (dev or production) that you have specified in your custom resource. For dev all the servers are grouped together and for production, each server has its own group. For a list of common properties for backend servers, see Common server properties for Inventory and Promising service groups. | |
jobs |
<List of auto-populated jobs> | object | A list of jobs that gets populated in the service group custom resource. For a list of common properties for jobs, see Properties specific to jobs. | |
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 service group
Deactivating an active service group means deleting it in the manner that it was created. For example,
- If a service group is created outside of
SIPEnvironment, you can only delete it from outside ofSIPEnvironment. In this case, set theactiveproperty to false to deactivate the service group. - If a service group is created inside the
SIPEnvironment, you can only delete it from theSIPEnvironment. In this case, do any of the following actions:- Remove the service group from
SIPEnvironment. - Update the service group to a different mode, dev or production as needed, to automatically deactivate the existing service group.
- Remove the service group from