Updating Parameters During Rerun of Environment or Configuration APIs
This section covers broadly these use case categories:
- How users can update some of the parameters during rerun of environment/configuration APIs to correct the invalid/incorrect values and resume the workflows.
- When an environment provisioning is triggered using an existing configuration, that
is
config_idis passed in payload and still one wants to use different infrastructure setup for environment keeping other configuration customizations. - Update the environment status as completed if the environment has failed in the App URL validation stage.
You can update parameters by passing them in payload for these API methods:
- PUT /environment - rerun of existing environment
- PUT /configuration - rerun of existing configuration
- POST /environment method which uses existing configuration, that is
config_idis passed in payload.
SCM allows to override only predefined set of parameters which are detailed in the following use case scenarios. For other parameters if overridden, validation error will be thrown. The reason for this is they are considered as immutable fields to keep the environment intact.
This section covers the following use cases:
- Use Case 1 - Non BYO Case - When "Use existing resources" Checkbox is Not Selected
- Use Case 2 - BYO Case - When "Use existing resources" Checkbox is Selected
- Use Case 3 - BYOD Case - When "Use existing resources" Checkbox is Not Selected and Only Existing Database is Used
- Use Case 4 - When running a CI activity needs env_status to be changed
- For all the following use cases, the parameters related to 'siebel' section cannot be overridden during API execution.
- Any other parameter, which is not mentioned in the respective use case, is not allowed to be overridden during API execution.
- For non-BYO use case, 'database' values cannot be overridden.
Use Case 1 - Non BYO Case - When "Use existing resources" Checkbox is Not Selected
For Non BYO Case, one can pass below parameters in payload during PUT or POST (when
config_id is passed in payload ) API execution.
-
CIDR parameters (only applicable when you chose Advanced Network Configuration during SCM stack creation)
- infrastructure > siebel_lb_subnet_cidr
- infrastructure > siebel_private_subnet_cidr
- infrastructure > siebel_db_subnet_cidr
- infrastructure > siebel_cluster_subnet_cidr
-
Size parameters
- size > ses_resource_limits
- size > sai_resource_limits
- size > cgw_resource_limits
- size > ses_resource_requests
- size > sai_resource_requests
- size > cgw_resource_requests
Here, it is not mandatory to pass all parameters. One can pass only required parameter during API execution.
Example Payload for PUT/POST method when "Use existing resources" Checkbox is Not Selected:
{
"infrastructure": {
"siebel_lb_subnet_cidr" : "10.0.1.0/24",
"siebel_private_subnet_cidr" : "10.0.2.0/24",
"siebel_db_subnet_cidr" : "10.0.3.0/24",
"siebel_cluster_subnet_cidr" : "10.0.4.0/24"
},
"ses_resource_limits": {
"cpu": "4",
"memory": "24Gi"
},
"ses_resource_requests": {
"cpu": "1",
"memory": "4Gi"
},
"sai_resource_limits": {
"cpu": "2",
"memory": "4Gi"
},
"sai_resource_requests: {
"cpu": "1",
"memory": "4Gi"
},
"cgw_resource_limits": {
"cpu": "2",
"memory": "4Gi"
},
"cgw_resource_requests”: {
"cpu": "1",
"memory": "4Gi"
}
}
}Use Case 2 - BYO Case - When "Use existing resources" Checkbox is Selected
config_id is passed in payload) API execution.-
OKE parameters
- infrastructure > kubernetes > byo_oke > oke_cluster_id
- infrastructure > kubernetes > byo_oke > oke_endpoint
- infrastructure > kubernetes > byo_oke > oke_kubeconfig_path
- infrastructure > mounttarget_exports
-
Database parameters - If you pass database section in payload, it is mandatory to pass all of the below fields.
- database > db_type
- database > byod
- database > auth_info
-
Size parameters
- size > ses_resource_limits
- size > sai_resource_limits
- size > cgw_resource_limits
- size > ses_resource_requests
- size > sai_resource_requests
- size > cgw_resource_requests
{
"infrastructure": {
"kubernetes": {
"kubernetes_type": "BYO_OKE",
"byo_oke": {
"oke_cluster_id": "<cluster-ocid>",
"oke_endpoint": "PRIVATE",
"oke_kubeconfig_path": "<path-to-kubeconfig-file>"
}
}
"mounttarget_exports": {
"siebfs_mt_export_paths": [
{
"mount_target_private_ip" : "10.0.0.82","export_path": "/siebfs0"
}
]
}
},
"database": {
"db_type": "BYOD",
"byod": {
"wallet_path": "/home/opc/siebel/wallet",
"tns_connection_name": "test_tp"
},
"auth_info": {
"admin_user_name": "*****",
"admin_user_password": "********",
"anonymous_user_password": "********",
"default_user_password": "*******",
"table_owner_password": "*******",
"table_owner_user": "******"
}
},
"size": {
"ses_resource_limits": {
"cpu": "4",
"memory": "24Gi"
},
"ses_resource_requests”: {
"cpu": "1",
"memory": "4Gi"
},
"sai_resource_limits": {
"cpu": "2",
"memory": "4Gi"
},
"sai_resource_requests": { "
cpu": "1",
"memory": "4Gi"
},
"cgw_resource_limits": {
"cpu": "2",
"memory": "4Gi"
},
"cgw_resource_requests": {
"cpu": "1",
"memory": "4Gi"
}
}
} Use Case 3 - BYOD Case - When "Use existing resources" Checkbox is Not Selected and Only Existing Database is Used
For BYO Case, one can pass the following parameters in payload during PUT or POST
(when config_id is passed in payload) API execution.
-
CIDR parameters (only applicable when you chose Advanced Network Configuration during SCM stack creation)
- infrastructure > siebel_lb_subnet_cidr
- infrastructure > siebel_private_subnet_cidr
- infrastructure > siebel_db_subnet_cidr
- infrastructure > siebel_cluster_subnet_cidr
-
Database parameters - If you pass database section in payload, it is mandatory to pass all the following fields.
- database > db_type
- database > byod
- database > auth_info
-
Size parameters
- size > ses_resource_limits
- size > sai_resource_limits
- size > cgw_resource_limits
- size > ses_resource_requests
- size > sai_resource_requests
- size > cgw_resource_requests
{
"infrastructure": {
"siebel_lb_subnet_cidr" : "10.0.1.0/24",
"siebel_private_subnet_cidr" : "10.0.2.0/24",
"siebel_db_subnet_cidr" : "10.0.3.0/24",
"siebel_cluster_subnet_cidr" : "10.0.4.0/24"
}
},
"database": {
"db_type": "BYOD",
"byod": {
"wallet_path": "/home/opc/siebel/wallet",
"tns_connection_name": "test_tp"
},
"auth_info": {
"admin_user_name": "*****",
"admin_user_password": "********",
"anonymous_user_password": "********",
"default_user_password": "*******",
"table_owner_password": "*******",
"table_owner_user": "******"
}
},
"ses_resource_limits": {
"cpu": "4",
"memory": "24Gi"
},
"ses_resource_requests": {
"cpu": "1",
"memory": "4Gi"
},
"sai_resource_limits": {
"cpu": "2",
"memory": "4Gi"
},
"sai_resource_requests": {
"cpu": "1",
"memory": "4Gi"
},
"cgw_resource_limits": {
"cpu": "2",
"memory": "4Gi"
},
"cgw_resource_requests": {
"cpu": "1",
"memory": "4Gi"
}
}
} Use Case 4 - When running a CI activity needs env_status to be changed
To run the CI activities of the Siebel CRM deployment such as SFS cleanup etc, the
environment has to be in a completed stage. The env_status
parameter will define if the environment is completed or not. If the environment has
failed in the app validation stage (because of some app urls not coming up), then
this API can be used to update the environment as completed.
Example:
PUT https://<CM_Instance_IP>:16690/scm/api/v1.0/environment/<env_id>
{
"env_status": "completed"
}