POC: Check how to pass hana db initialisation config when provisioning btp hana service instance

[kwiatekus]

Description

Allow automating hana db initialization (schema, tables etc) via kyma cli.

Exemplary flow:

1. kyma provision
2. create hana instance & bind it
3. initialize hana via hana hdi containers

Execute the flow manually and document findings as a comment in the issue. Propose how should we approach this in the Kyma CLI?

Reasons

This feature is required for fully automated deployments for apps relying on hana cloud db instance.

Attachments

Example app and the necessary manual step that should be avoided hana cloud hdi instantiation in kyma Manual Example configuration

[halamix2]

1. go run . provision --credentials-path cis_local.json --plan aws --region eu-central-1 --owner email @ email.com
2. go run . hana provision --kubeconfig kubeconfig.yaml --name hana
3. Add entitlement hana-cloud -> admin-api-access & add its instance & binding

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: hania-api
  labels:
    app.kubernetes.io/name: hania-api
  annotations: {}
  namespace: default
spec:
  serviceOfferingName: hana-cloud
  servicePlanName: admin-api-access
  parameters:
    technicalUser: true
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: hania-api
  labels:
    app.kubernetes.io/name: hania-api
  annotations: {}
  namespace: default
spec:
  serviceInstanceName: hania-api
  secretName: hania-api

4. Read the baseurl and uaa fields from the baseurl binding secret
5. Call POST ${uaa.url}/oauth/token with basic auth of uaa.clientid / uaa.clientsecret and url-encoded body grant_type=client_credentials; get access_token
6. Get Kyma cluster ID: kubectl get configmap sap-btp-operator-config -n kyma-system -o jsonpath='{.data.CLUSTER_ID}'
7. Call POST ${baseurl}/inventory/v2/serviceInstances/${hana_instance_guid}/instanceMappings with access_token as Bearer token and following body:

{
  "platform": "kubernetes",
  "primaryID": "<kyma_id>"
}

8. initialize hana via hana hdi containers
   • In Kyma create Hana instance in the default namespace
     • Service Management -> Service Instances -> Create
     • offering name - hana, plan name - hdi-shared

     apiVersion: services.cloud.sap.com/v1
     kind: ServiceInstance
     metadata:
       name: hdi
       labels:
         app.kubernetes.io/name: hdi
       annotations: {}
       namespace: default
     spec:
       serviceOfferingName: hana
       servicePlanName: hdi-shared
     

[halamix2]

I'll add steps 3-7 to the kyma hana map command, as without this mapping Hana is useless on a cluster Stel 8 should be in its own command

[halamix2]

Current example flow (assuming the Keda cluster exists):

1. Initialize Hana database: kyma hana provision --kubeconfig kubeconfig.yaml --name hania
   • creates ServiceInstance for hana-cloud/hana & ServiceBindings - hana & hana-url
2. Map Hana DB to the cluster: kyma hana map --kubeconfig kubeconfig.yaml --name hania
   • this is separate step, as Hana initialization takes ~5mins, and the setup for mapping another minute
   • creates ServiceInstance & ServiceBinding for hana-cloud/admin-api-access
   • creates cluster mapping in Hana using the Hana API
3. Create rest manually using standard Kubernetes resources, and apply them with e.g kubectl apply -f (or Busola), see example at https://github.tools.sap/fp-stakeholder-management/hana-cloud/tree/main/kyma-easy/faas/kyma-fun/kyma/helm/faas-db/templates:
   • HDI/schema ServiceInstance
   • HDI/schema tables and definitions as ConfigMap
   • HDI/schema initialization as Job, using ConfigMap

[kwiatekus]

step 3 ☝️ is possible to do with just kubectl once you read the (scattered) docs of hana HDI and about managing instances via btp operator in kyma. So its complicated for non fluent devs who dont know k8s or sap btp.

Handling that via cli could definitely make it easier but for us it would be difficult to design it as easy to use and enable maximum control over db initialisation. Also its locking us a bit to use externally vendored image.

I would skip it for now and learn more about user expectations. What do you think @ptesny @pbochynski @varbanv

[kwiatekus]

@halamix2 printing a description with links to HDI usage dosc could be just fine at this stage of development. sth that gives user enough hints and a direct call for action to proceed

[ptesny]

here goes one of my hdi samples with the hdi container data in a config map;

https://github.tools.sap/fp-stakeholder-management/hana-cloud/tree/main/kyma-easy/faas/kyma-fun/kyma/helm/faas-db

Worth saying, instead of creating a hdi-deployer container with the hdi container data (coming from a config map) I use a stock public docker image of a hdi-deployer and have job to run the hdi deployment. With all the hdi conatiner design-timer arftefacts mounted as volumes with the hdi-deployer image.