Tenant Subscription
2 minute read
From the perspective of CAP Operator, a valid tenant for an application is represented by the resource CAPTenant. It refers to the CAPApplication it belongs to and specifies the details of the SAP BTP subaccount representing the tenant.
apiVersion: sme.sap.com/v1alpha1
kind: CAPTenant
metadata:
name: cap-app-01-provider
namespace: cap-app-01
spec:
capApplicationInstance: cap-app-01 # <-- reference to the CAPApplication
subDomain: app-provider
tenantId: aa2bae55d7b5-1279-456564-a7b0-aa2bae55d7b5
version: "1.0.0" # <-- expected version of the application
versionUpgradeStrategy: always # <-- always / never
Tenant Provisioning
The process of tenant provisioning starts when a consumer subaccount subscribes to the application, either via the SAP BTP cockpit or using the APIs provided by the SaaS provisioning service. This, in turn, initiates the asynchronous callback from the SaaS provisioning service instance into the cluster, and the request is handled by the subscription server. The subscription server validates the request and creates an instance of CAPTenant for the identified CAPApplication.
Warning
An instance ofCAPTenant must not be created or deleted manually within the cluster. A new instance has to be created by the subscription server after receiving a provisioning call from SaaS provisioning service.The controller, observing the new CAPTenant, will initiate the provisioning process by creating the resource CAPTenantOperation, which represents the provisioning operation.
apiVersion: sme.sap.com/v1alpha1
kind: CAPTenantOperation
metadata:
name: cap-app-01-provider-sgz8b
namespace: cap-app-01
spec:
capApplicationVersionInstance: cav-cap-app-01-1 # <-- latest CAPApplicationVersion in Ready state
subDomain: app-provider
tenantId: aa2bae55d7b5-1279-456564-a7b0-aa2bae55d7b5
operation: provisioning # <-- valid values are provisioning, deprovisioning and upgrade
steps:
- name: cap-backend # <-- derived from workload of type CAP (when workload of type TenantOperation is not specified)
type: TenantOperation
The CAPTenantOperation is further reconciled to create Kubernetes jobs (steps), which are derived from the latest CAPApplicationVersion, which is in Ready state. The steps comprise of a TenantOperation job and optional CustomTenantOperation steps. The TenantOperation step uses built in CLI-based tenant operations from @sap/cds-mtxs to execute tenant provisioning.
The CAPTenant reaches a Ready state, only after
- a successful completion of all
CAPTenantOperationsteps. - the creation of Istio
VirtualService, which allows HTTP requests on the tenant subdomain to reach the application.
Tenant Deprovisioning
Similar to the tenant provisioning process, when a tenant unsubscribes from the application, the request is received by the subscription server. It validates the existence and status of the CAPTenant and submits a request for deletion to the Kubernetes API server.
The controller identifies that the CAPTenant has to be deleted, but withholds deletion until it can create and watch for a successful completion of a CAPTenantOperation of type deprovisioning. The CAPTenantOperation creates the corresponding jobs (steps), which execute the tenant deprovisioning.