This topic explains how you can troubleshoot issues related to working with services on Tanzu Application Platform (commonly known as TAP).
For the limitations of services on Tanzu Application Platform, see Services Toolkit limitations.
This section provides guidance on how to debug issues related to using ClassClaim
and provisioner-based ClusterInstanceClass
. The approach starts by inspecting a ClassClaim
and tracing back through the chain of resources that are created when fulfilling the ClassClaim
.
To follow the steps in this section, you must have kubectl access to the cluster.
Inspect the status of ClassClaim
by running:
kubectl describe classclaim claim-name -n NAMESPACE
Where NAMESPACE
is your namespace.
From the output, check the following:
.spec.classRef.name
and record the value.Inspect the status of the ClusterInstanceClass
by running:
kubectl describe clusterinstanceclass CLASS-NAME
Where CLASS-NAME
is the value of .spec.classRef.name
you retrieved in the previous step.
From the output, check the following:
Ready
condition has status "True"
..spec.provisioner.crossplane
and record the value.Inspect the status of the CompositeResourceDefinition
by running:
kubectl describe xrd XRD-NAME
Where XRD-NAME
is the value of .spec.provisioner.crossplane
you retrieved in the previous step.
From the output, check the following:
Established
condition has status "True"
.ClusterInstanceClass
reports Ready="True"
and the CompositeResourceDefinition
reports Established="True"
, move on to the next section.Check .status.provisionedResourceRef
by running:
kubectl describe classclaim claim-name -n NAMESPACE
Where NAMESPACE
is your namespace.
From the output, check the following:
.status.provisionedResourceRef
, and record the values of kind
, apiVersion
, and name
.Inspect the status of the Composite Resource by running:
kubectl describe KIND.API-GROUP NAME
Where:
KIND
is the value of kind
you retrieved in the previous step.API-GROUP
is the value of apiVersion
you retrieved in the previous step without the /<version>
part.NAME
is the value of name
you retrieved in the previous step.From the output, check the following:
.spec.resourceRefs
in the output and for each:
kind
, apiVersion
, and name
to inspect the status of the Managed Resource.Inspect the events log by running:
kubectl get events -A
From the output, check the following:
Check .status.resourceRef
by running:
kubectl get classclaim claim-name -n NAMESPACE -o yaml
Where NAMESPACE
is your namespace.
From the output, check the following:
.status.resourceRef
and record the values kind
, apiVersion
, name
, and namespace
Inspect the claimed resource, which is likely a secret, by running:
kubectl get secret NAME -n NAMESPACE -o yaml
Where:
NAME
is the name
you retrieved in the previous step.NAMESPACE
is the namespace
you retrieved in the previous step.If the secret is there and has data, then something else must be causing the issue.
If you have followed the steps in this section and are still unable to discover the cause of the issue, contact VMware Support for further guidance and help to resolve the issue.
Symptom:
When creating a CompositeResourceDefinition
, if you set additionalProperties: true
in the openAPIV3Schema
section, an error occurs during the validation step of the creation of any ClassClaim
that refers to a class that refers to the CompositeResourceDefinitions
.
The error appears as follows:
json: cannot unmarshal bool into Go struct field JSONSchemaProps.AdditionalProperties of type apiextensions.JSONSchemaPropsOrBool
Solution:
Rather than setting additionalProperties: true
, you can set additionalProperties: {}
. This has the same effect, but does not cause unexpected errors.
Symptom:
Users who were previously able to create a ClassClaim
now get an admission error similar to:
user '[email protected]' cannot 'claim' from clusterinstanceclass 'bigcorp-rabbitmq'
This occurs even if users were granted the claim
permission on ClusterInstanceClasses
through either:
Role
and a RoleBinding
ClusterRole
and a RoleBinding
Explanation:
You now need the cluster-level claim
permission, granted through a ClusterRole
and ClusterRoleBinding
. Namespace-scoped permissions are no longer enough. This is to protect against unexpected access to resources in other namespaces.
This change was introduced with Services Toolkit v0.12.0 in Tanzu Application Platform v1.7.0. For more information about this change, see The claim verb for ClusterInstanceClass.
Solution:
To allow users to create ClassClaims
again, you must:
Role
to a ClusterRole
for granting users permission to claim a ClusterInstanceClass
.RoleBinding
to a ClusterRoleBinding
for binding this permission to a user.For more information, see Authorize users and groups to claim from provisioner-based classes.