ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
75b9e25e680705ea0d5cc4eb73f74aff6d2bb14a
nexus/knowledgebase/csd-wiki/ICSD/OP-tenant-decommission-process_690087778.md
weishen 3f2e1765d8 Auto-sync: 2026-04-18 17:09
2026-04-18 17:09:43 +08:00

16 KiB
Raw Blame History

OP-tenant-decommission-process_690087778

Introduction

This guide introduce the decommission process for the Operation Platform tenant.

Delete the HCMX tenant

Delete the OP tenant

Deployment Parameters

Ensure that following parameters are set appropriately

S.No Parameter Value Significance Reference
1 global.di.enableHardPartitionMT true To enable multi-tenant phase 2 deployment
2 global.idm.tenant The Super Admin Org to which the administrator belongs too.
3 global.idm.integrationUser The IDM User who has permission to list the IDM tenants and create roles in IDM
4 global.idm.integrationUserKey The vault secret key that contains the password for IDM user specified in global.idm.integrationUser helm parameter
5 itomditenantmgmt.ditenantmgmt.db.dbauser The DBA Admin user who has permission to create users, resource pools, grant permissions, delete users and delete resource pools
6 itomditenantmgmt.ditenantmgmt.db.dbauserkey The vault secret key that contains the password for DBA user specified in itomditenantmgmt.ditenantmgmt.db.dbauser helm parameter. This key should be present in prehook secret (global.preHookSecret) and also in the default secret.
7 .Values.itomdimonitoring.monitoringDBUser The vertica user which needs to be used for monitoring dashboards. The user should match with the monitoring user created by dbinit.
8 .Values.itomdimonitoring.monitoringDBUserKey The vault secret key that contains the password for the vertica monitoring user specified in.Values.itomdimonitoring.monitoringDBUser helm parameter. The password should match with the monitoring user password in vertica.

Note

  1. The pre-hook secret (specified by global.preHookSecret) should contain the DBA User Password key specified by (itomditenantmgmt.ditenantmgmt.db.dbauserkey) helm parameter

Chart Installation

helm install itomditenantmgmt <location_of_chart_tgz> -n <namespace> -f <location_to_params_yaml>

Swagger SPEC

TMS Swagger Spec is available here

Steps to Onboard Tenant

  1. Get IDM Token for a user who as SUPER_IDM_PERMISSION curl
    -k -X POST
    https:``// <ingress- hostname >:<ingress-port> /idm-service/v3``.0 /tokens
    -H  'content-type: application/json' -d  '{"passwordCredentials":{"username":"username","password":"password"},"tenantName":"idmOrgName"}'

    # idmOrgName should be same as the org specified in global.idm.tenant
    #The user must have SUPER_IDM_PERMISSION

  2. Perform TMS API Call as per the spec using the IDM token extracted in step1.

curl -k -X POST  "https://<hostname>:<ingress-port>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants"
--header  'Content-Type: application/json' --header  "X-Auth-Token:" (Token fetched in the previous step) --data  @tenant_onboard_request_tenant1``.json

### Sample Json (tenant_onboard_request_tenant1.json)

{
"id"``: ``"tenant_x"``,
"name"``: ``"tenant_x"``,
"idmOrgName"``: ``"tenant_x"``,
"tenantParameters"``: {
"dbTenantName"``: ``"tenant_x"``,
"rwUser"``: ``"tenant_x_rw_user"``,
"rwUserPassword"``: ``"dbrw#tenant1"``,
"roUser"``: ``"tenant_x_ro_user"``,
"roUserPassword"``: ``"dbro#tenant1"``,
"resourcePools"``: [
{
"name"``: ``"itom_di_streaming_tenant_x_deployment"``,
"purpose"``: ``"streaming"``,
"memorySize"``: ``1038``,
"memoryUnit"``: ``"MB"``,
"plannedConcurrency"``: ``4
},
{
"name"``: ``"itom_di_monitoring_tenant_x_deployment"``,
"purpose"``: ``"monitoring"``,
"memorySize"``: ``250``,
"maxMemorySize"``: ``500``,
"memoryUnit"``: ``"MB"
},
{
"name"``: ``"itom_di_postload_tenant_x_deployment"``,
"purpose"``: ``"postload"``,
"memorySize"``: ``1038``,
"maxMemorySize"``: ``3072``,
"memoryUnit"``: ``"MB"
},
{
"name"``: ``"itom_di_dataaccess_tenant_x_deployment"``,
"purpose"``: ``"dataaccess"``,
"memorySize"``: ``1038``,
"memoryUnit"``: ``"MB"
}
],
"mbusTenantName"``: ``"tenant_x"``,
"backlogQuotaInMB"``: ``20``,
"ingestionRateInMBPerSec"``: ``2
}
}

###### Sample Response ##############
{
"job_id"``: ``"44e3320b-7b8e-459e-a091-47b34a72f31e"``,
"operation"``: ``"DEPLOY"
}

3. Note down the job_id obtained as response. This job_id can be used to track the status of tenant onboarding.

Steps to check the status of the tenant

  1. Get IDM Token for a user who as SUPER_IDM_PERMISSION

curl
-k -X POST
https:``// <ingress- hostname >:<ingress-port> /idm-service/v3``.0 /tokens
-H  'content-type: application/json' -d  '{"passwordCredentials":{"username":"username","password":"password"},"tenantName":"idmOrgName"}'

# idmOrgName should be same as the org specified in global.idm.tenant
#The user must have SUPER_IDM_PERMISSION

2. Perform TMS API Call as per the spec using the IDM token extracted in step1.

curl -k -X GET  "https://<hostName>:<ingressPort>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants/<tenant_id>/tenant-jobs/<tenant_deploy_jobId>" --header  'Content-Type: application/json' --header  "X-Auth-Token:" (Token fetched in the previous step) 

3. If the job_status is successful, then tenant has been onboarded in pulsar, vertica and ODL Services. The ODL application specific roles are created in IDM.

4. If the job_status is failure, then tenant specific GET API can be used to find the reason for failure.

4.a GET API to view the status of specific tenant.

curl -k -X GET  "https://<hostName>:<ingressPort>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants/<tenant_id>" --header  'Content-Type: application/json' --header  "X-Auth-Token:" (Token fetched in the previous step) 

Steps to list all the tenants

  1. Get IDM Token for a user who as SUPER_IDM_PERMISSION

curl
-k -X POST
https:``// <ingress- hostname >:<ingress-port> /idm-service/v3``.0 /tokens
-H  'content-type: application/json' -d  '{"passwordCredentials":{"username":"username","password":"password"},"tenantName":"idmOrgName"}'

# idmOrgName should be same as the org specified in global.idm.tenant
#The user must have SUPER_IDM_PERMISSION

2. Perform TMS API Call as per the spec using the IDM token extracted in step1.

curl -k -X GET  "https://<hostName>:<ingressPort>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants" --header  'Content-Type: application/json' --header  "X-Auth-Token:" (Token fetched in the previous step) 

Patch Tenant

Steps to decommission tenant

Only Tenants in deactivated state can be decommissioned.

Decommissioning an active tenant is a two step process.

  1. De-activate a tenant using PATCH API
  2. Decommission the tenant using DELETE API

De-activate the tenant

    1. Get IDM Token for a user who as SUPER_IDM_PERMISSION curl
      -k -X POST
      https:``// <ingress- hostname >:<ingress-port> /idm-service/v3``.0 /tokens
      -H  'content-type: application/json' -d  '{"passwordCredentials":{"username":"username","password":"password"},"tenantName":"idmOrgName"}'

      # idmOrgName should be same as the org specified in global.idm.tenant
      #The user must have SUPER_IDM_PERMISSION b. Perform TMS API Call as per the spec using the IDM token extracted in step1.

  2. curl -k -X PATCH  "https://<hostname>:<ingress-port>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants/<tenant id>" --header  'Content-Type: application/json-patch+json' --header  "X-Auth-Token:" (Token fetched  in the previous step) --data @tenant_patch_request_tenant1.json

    ### Sample Json (tenant_patch_request_tenant1.json)

    [
    {
    "op"``: ``"replace"``,
    "path"``: ``"state"``,
    "value"``: ``"DE-ACTIVATED"
    }
    ]

    ### Sample Request to patch tenant_x
    curl -k -X PATCH  "https://<hostname>:<ingress-port>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants/tenant_x" --header  'Content-Type: application/json-patch+json' --header  "X-Auth-Token:" (Token fetched  in the previous step) --data @tenant_patch_request_tenant1.json

    ###### Sample Response ##############
    {
    "job_id"``: ``"44e3320b-7b8e-459e-a091-47b34a72f31e"``,
    "operation"``: ``"DEPLOY"
    }  

De-commission the tenant

    1. Get IDM Token for a user who as SUPER_IDM_PERMISSION curl
      -k -X POST
      https:``// <ingress- hostname >:<ingress-port> /idm-service/v3``.0 /tokens
      -H  'content-type: application/json' -d  '{"passwordCredentials":{"username":"username","password":"password"},"tenantName":"idmOrgName"}'

    # idmOrgName should be same as the org specified in global.idm.tenant
    #The user must have SUPER_IDM_PERMISSION b. Perform TMS API Call as per the spec using the IDM token extracted in step1. curl -k -X DELETE  "https://<hostName>:<ingressPort>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants/<tenant id>" --header  'Content-Type: application/json' --header  "X-Auth-Token:" (Token fetched in the previous step) 

    ### Sample call to delete a tenant with tenant id tenant_x

    curl -k -X DELETE  "https://<hostName>:<ingressPort>/itom-data-ingestion-tenant-mgmt/urest/v1/tenants/tenant_x" --header  'Content-Type: application/json' --header  "X-Auth-Token:" (Token fetched in the previous step)

Steps to decommission tenant in PENDING-FOR-REMOVAL state

1. Delete pulsar tenant

    1. Exec into pulsar bastion pod

kubectl -n <k8s namespace>  exec -it itomdipulsar-bastion-0 -c pulsar sh

##### Example:
kubectl -n coso   exec -it itomdipulsar-bastion-0 -c pulsar sh

b. Delete the pulsar tenant

/pulsar/bin/pulsar-admin tenants delete <pulsar tenant name>

##### Example:
/pulsar/bin/pulsar-admin tenants delete tenant_x

2. Delete the IDM Roles

    1. Get IDM Token for a user who has permissions to delete roles

      1. curl
        -k -X POST
        https:``// <ingress- hostname >:<ingress-port> /idm-service/v3``.0 /tokens
        -H  'content-type: application/json' -d  '{"passwordCredentials":{"username":"username","password":"password"},"tenantName":"idmOrgName"}'

        # idmOrgName should be same as the org specified in global.idm.tenant
        #The user must have SUPER_IDM_PERMISSION

b. Perform IDM delete role API Call to delete di_data_access, di_ingestion, di_admin using the IDM token extracted in step1.

curl -k -X DELETE https:``//sac-hvm03929.swinfra.net:19443/idm-service/api/scim/organizations/<idm org name>/roles/di_data_access" --header 'Content-Type: application/json' --header "X-Auth-Token:"(Token fetched in the previous step) 
curl -k -X DELETE https:``//sac-hvm03929.swinfra.net:19443/idm-service/api/scim/organizations/<idm org name>/roles/di_ingestion" --header 'Content-Type: application/json' --header "X-Auth-Token:"(Token fetched in the previous step)  
curl -k -X DELETE https:``//sac-hvm03929.swinfra.net:19443/idm-service/api/scim/organizations/<idm org name>/roles/di_admin" --header 'Content-Type: application/json' --header "X-Auth-Token:"(Token fetched in the previous step) 

### Sample call to delete a tenant with tenant id tenant_x  

curl -k -X DELETE https:``//sac-hvm03929.swinfra.net:19443/idm-service/api/scim/organizations/tenant_x/roles/di_data_access" --header 'Content-Type: application/json' --header "X-Auth-Token:"(Token fetched in the previous step) 
curl -k -X DELETE https:``//sac-hvm03929.swinfra.net:19443/idm-service/api/scim/organizations/tenant_x/roles/di_ingestion" --header 'Content-Type: application/json' --header "X-Auth-Token:"(Token fetched in the previous step)  
curl -k -X DELETE https:``//sac-hvm03929.swinfra.net:19443/idm-service/api/scim/organizations/tenant_x/roles/di_admin" --header 'Content-Type: application/json' --header "X-Auth-Token:"(Token fetched in the previous step)

3. Clean up Vertica

1. Clean up resource pools

a. Get the list of resource pools

select LISTAGG(user_name) as  users from itom_di_tenant_management_difarm_default.db_users where tenant_id= '<tenant id>'``;
## Example:
select LISTAGG(user_name) as  users from itom_di_tenant_management_difarm_default.db_users where tenant_id= 'tenant_x'``;

b. Delete the resource pools

drop resource pool <output of previous query>

Example:
drop resource pool itom_di_other_tenant_x_deployment_1,itom_di_streaming_tenant_x_deployment_1;

2. Clean up tenant related information in TMS schema

delete from itom_di_tenant_management_difarm_default.db_users where tenant_id= '<tenant id>'``;
delete from itom_di_tenant_management_difarm_default.resource_pools where tenant_id= '<tenant id>'``;
delete from itom_di_tenant_management_difarm_default.tenant where tenant_id= '<tenant id>'``;
delete from itom_di_tenant_management_difarm_default.tenant_job_messages where job_id  in (``select job_id from itom_di_tenant_management_difarm_default.tenant_jobs where tenant_id= '<tenant id>'``);
delete from itom_di_tenant_management_difarm_default.tenant_jobs where tenant_id= '<tenant id>'``;

### Example

delete from itom_di_tenant_management_difarm_default.db_users where tenant_id= 'tenant_x'``;
delete from itom_di_tenant_management_difarm_default.resource_pools where tenant_id= 'tenant_x'``;
delete from itom_di_tenant_management_difarm_default.tenant where tenant_id= 'tenant_x'``;
delete from itom_di_tenant_management_difarm_default.tenant_job_messages where job_id  in (``select job_id from itom_di_tenant_management_difarm_default.tenant_jobs where tenant_id= 'tenant_x'``);
delete from itom_di_tenant_management_difarm_default.tenant_jobs where tenant_id= 'tenant_x'``;

3. Clean up the tenant specific users

a. Extract the tenant specific users

select LISTAGG(user_name) as  users from itom_di_tenant_management_difarm_default.db_users where tenant_id= '<tenant_id>'``;

##Example:
select LISTAGG(user_name) as  users from itom_di_tenant_management_difarm_default.db_users where tenant_id= 'tenant_x'``;

b. Delete the tenant specific users

drop user <output of previous query> cascade;

## Example:

drop user tenant_12_ro_user,tenant_12_rw_user cascade;

Note

  1. The ODL pods will be up and running irrespective of existence of tenants in the deployment
  2. Upgrade from non-MT to Phase-2 MT or existing MT to Phase-2 MT deployment will not be supported
  3. If Configuration and Streaming is performed by a user who is part of superOrg, then X-TenantID header should be specified in the request whose value points to the tenant on which the operation needs to be performed.
  4. Only ODL roles (di_admin, di_ingestion, di_data_access) will be created in IDM. The administrator needs to create users and associate appropriate roles for configuration and streaming.

Related pages

Reference in New Issue View Git Blame Copy Permalink