Question regarding Cross subaccount service manager accessing (multitenancy?)
jingweiz2017 opened this issue · comments
Hello there,
I was trying to config my sap-btp-operator to access the CF Service Manager on another subaccount. I think this is referred by the multitenancy section.
I setup the operator with:
curl -s https://raw.githubusercontent.com/SAP/sap-btp-service-operator/main/hack/setup_operator_env.sh |
bash -s '' '' <sm_url> -n
And then used "kubectl-sapbtp" to verify the availability of btp service to my namespace.
They all work fine. And I can see a list of services.
However, when I try to create a service instance, it will either show
"message: invalid Service-Manager credentials, contact your cluster administrator"
or
"message: 'error sending request GET /v1/service_instances: Get "https://service-manager.cfapps.sap.hana.ondemand.com/v1/service_instances?attach_last_operations=true&fieldQuery=name+eq+%27auditlog-instance-1658%27+and+context%2Fclusterid+eq+%27747f5c44-d6e6-483f-90e9-125c361ee549%27+and+context%2Fnamespace+eq+%27wr-develop%27&labelQuery=_k8sname+eq+%27auditlog-instance-1658%27":
oauth2: cannot parse json: invalid character ''<'' looking for beginning of"
Can you provide some suggestion to help to debug this issue?
Thank you
The script setup_operator_env.sh was initially created for internal use and hasn't been updated for some time. Please set up your environment following the documentation provided here:
https://github.com/SAP/sap-btp-service-operator/?tab=readme-ov-file#working-with-multiple-subaccounts
If you encounter any issues during the setup, please feel free to contact us for assistance.
I was trying to following the document but was blocked by the error below:
Release "sap-btp-operator" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: CustomResourceDefinition "servicebindings.services.cloud.sap.com" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: key "app.kubernetes.io/managed-by" must equal "Helm": current value is "btp-manager"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "sap-btp-operator"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "sap-btp-operator-ns"
And following is the command I tried to run:
helm upgrade --install sap-btp-operator sap-btp-operator/sap-btp-operator
--create-namespace
--namespace=sap-btp-operator-ns
--set manager.secret.clientid=
--set manager.secret.clientsecret=
--set manager.secret.sm_url='https://service-manager.cfapps.sap.hana.ondemand.com'
--set manager.secret.tokenurl='https://<project_name>.authentication.sap.hana.ondemand.com'
--set manager.management_namespace='kyma-system' -n sap-btp-operator-ns
Other questions:
- How do I specify the "Runtime Environment" in the service instance CR to provision the service instance? E.g. cloud-logging can be provisioned on cf and kyma, as well. By default, it takes kyma and I want CF instead.
- Service binding can only be created after Service Instance is there in the namespace. If I had a service instance provisioned(shared service) through btp cockpit on CF, how do I config the service instance CR to map to that existed CF service instance? I saw operationType for Service Instance only take "CREATE, UPDATE, or DELETE" as possible values.
I was trying to following the document but was blocked by the error below: Release "sap-btp-operator" does not exist. Installing it now. Error: rendered manifests contain a resource that already exists. Unable to continue with install: CustomResourceDefinition "servicebindings.services.cloud.sap.com" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: key "app.kubernetes.io/managed-by" must equal "Helm": current value is "btp-manager"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "sap-btp-operator"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "sap-btp-operator-ns"
And following is the command I tried to run: helm upgrade --install sap-btp-operator sap-btp-operator/sap-btp-operator --create-namespace --namespace=sap-btp-operator-ns --set manager.secret.clientid= --set manager.secret.clientsecret= --set manager.secret.sm_url='https://service-manager.cfapps.sap.hana.ondemand.com' --set manager.secret.tokenurl='https://<project_name>.authentication.sap.hana.ondemand.com' --set manager.management_namespace='kyma-system' -n sap-btp-operator-ns
For this one, I think the issue is caused by "btp-manager-controller-manager-56759f5b7f-6jbxw ". It will reconcile any cluster wide objects like crd and assign itself as owner while the helm upgrade install is expecting "Helm". I'm able to finish the installation on a newly created kyma environment without this btp-manager on it.
Given that the cluster was not installed using the helm script, it won't override your CRD, If your cluster doesn't contain crucial content, you have the option to clean the cluster and perform a fresh installation using helm.
However, if you're unable to do that, it's essential to investigate and identify discrepancies between your secret and the recommended secret structure in our documentation. It seems that the script might be utilizing a url instead of sm_url. Addressing any mismatches or errors in the secret configuration should help resolve the original issue.
Given that the cluster was not installed using the helm script, it won't override your CRD, If your cluster doesn't contain crucial content, you have the option to clean the cluster and perform a fresh installation using helm.
However, if you're unable to do that, it's essential to investigate and identify discrepancies between your secret and the recommended secret structure in our documentation. It seems that the script might be utilizing a url instead of sm_url. Addressing any mismatches or errors in the secret configuration should help resolve the original issue.
Thanks for your reply. I had a new installation with helm, now.
Can you help to answer the following two questions?
- How do I specify the "Runtime Environment" in the service instance CR to provision the service instance? E.g. cloud-logging can be provisioned on cf and kyma, as well. By default, it takes kyma and I want CF instead.
- Service binding can only be created after Service Instance is there in the namespace. If I had a service instance provisioned(shared service) through btp cockpit on CF, how do I config the service instance CR to map to that existed CF service instance? I saw operationType for Service Instance only take "CREATE, UPDATE, or DELETE" as possible values.
The runtime of the instance is decided upon the provisioning environment. If you are consuming it within CF, it becomes a CF entity.
To establish this, you should initiate a shared instance within the cluster and subsequently create a binding to it.
the instance should have plan 'reference-instance' and parameter: '{"referenced_instance_id":"CF-Instance-ID"}'.
The runtime of the instance is decided upon the provisioning environment. If you are consuming it within CF, it becomes a CF entity. To establish this, you should initiate a shared instance within the cluster and subsequently create a binding to it. the instance should have plan 'reference-instance' and parameter: '{"referenced_instance_id":"CF-Instance-ID"}'.
Thank you very much for the suggestion.
I looked into this approach. I think it only applies for CF Service Instance that is under the same subaccount as of the kyma application. Cross subaccount scenario like having kyma application under one subaccount to access CF serviceinstance on a different subaccount is not applicable. Right?
this is relevant only to instances within the same subaccount.
thanks for your support. I'm closing this issue.