Test case 2: SB + postgresql running in different namespaces

[cmoulliard]

Scenario

Title: Spring Boot Petclinic application and postgresql are running in DIFFERENT namespaces.

Reference: TAP documentation to play the different scenario using RabbitMQ - here

Steps:

1. Have access to a k8s cluster and TAP
2. Have a postgresql DB deployed within a namespace (e.g demo-4)
3. Create a ResourceClaimPolicy within the namespace hosting the DB

cat << EOF | kubectl apply -f -
---
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ResourceClaimPolicy
metadata:
  name: postgres-db-cross-namespace
  namespace: demo-4
spec:
  consumingNamespaces:
  - '*'
  subject:
    group: sql.tanzu.vmware.com
    kind: Postgres
EOF
resourceclaimpolicy.services.apps.tanzu.vmware.com/postgres-db-cross-namespace created

4. Create a Resourceclaim within the application namespace using the information that you can grab from commands tanzu service types list and tanzu service instances list -A such as APIVERSION, Kind, namespace and service name

tanzu service claim create postgresdb-1 -n demo-3 \
  --resource-name postgres-db \
  --resource-namespace demo-4 \
  --resource-kind Postgres \
  --resource-api-version sql.tanzu.vmware.com/v1

5. Get the ResourceClaimReference and pass it to the workload

tanzu services claims get postgresdb-1 -n demo-3
...
Claim Reference: services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:postgresdb-1 <<<< HERE

7. Create a workload in a DIFFERENT namespace

APP=spring-tap-petclinic
tanzu apps workload create $APP \
  -n demo-3 \
  --git-repo https://github.com/halkyonio/$APP.git \
  --git-branch main\
  --type web \
  --annotation "autoscaling.knative.dev/scaleDownDelay=15m" \
  --annotation "autoscaling.knative.dev/minScale=1" \
  --env "SPRING_PROFILES_ACTIVE=postgres" \
  --label app.kubernetes.io/part-of=$APP\
  --service-ref "db=services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:postgresdb-1" \
  -y

Expected

• Knative service within the Namespace: Yes
• ClusterResource/postgresql: Yes
• Postgres/postgres-db within the namespace (e.g demo-4): Yes
• ResourceClaimPolicy/postgres-db-cross-namespace within the DB namespace: Yes
• ResourceClaim within the application namespace: Yes

Results:

Wait and check the workload's deployment using these commands:

APP=spring-tap-petclinic
tanzu apps -n demo-3 workload get $APP

## Get the URL of the service and open the URL  in your browser
kc get ksvc/$APP -n demo-3 -o json | jq .status.address.url

Resources checked and their result:

• kc get ClusterResource/postgresql: YES
• kc get Postgres/postgres-db -n demo-4: YES
• kc get resourceclaim -n demo-3: YES
• kc get ResourceClaimPolicy/postgres-db-cross-namespace -n demo-4 YES

Conclusion

The Spring Boot Petclinic Application has been well deployed, the URL of the service is accessible.
A Resourceclaim has been needed to be created.
The Resourceclaim has been used to bind the DB (running in a separate namespace) with the Knative Service.

See the SBO spec section

spec:
  name: db
  service:
    apiVersion: services.apps.tanzu.vmware.com/v1alpha1
    kind: ResourceClaim
    name: postgresdb-1
  workload:
    apiVersion: serving.knative.dev/v1
    kind: Service
    name: spring-tap-petclinic
status:
  binding:
    name: postgres-db-app-user-db-secret

Question: As the Config Template executed by the step app-config of the supplychain source-to-url includes the logic to populate a ResourceClaim, why do we have then to create a ResourceClaim manually - see code ?

To cleanup

APP=spring-tap-petclinic
tanzu apps workload delete $APP -n demo-3 -y
kc get ResourceClaimPolicy/postgres-db-cross-namespace -n demo-4