Getting namespace from spec instead of metadata

[althaf1088]

Hi Team,

We are using sap-btp-service-operator with Crossplane, to take advantage of the secret rotation functionality provided by the operator following the documentation here

Due to Crossplane design for Composition, we cannot add metadata.namespace since it is not designed to support namespace scoped resources.Crossplane namespace issue

So would like to check if its feasible to get the namespace either from metadata or from spec.forprovider like (code) for other provider mentioned here

This will help us to avoid any workaround and also to fully use the functionalities of crossplane .

[thonacker]

@kerenlahav Can you help here? This would be very helpful for us moving forward with Crossplane as orchestration tool

[kerenlahav]

Hi,
I dont undertand the request, how are you working with the operator? the operator reacts to CRs, where are you creating the CRs? how the CR looks like? please share as much details as possible.

Thanks.

[althaf1088]

Hi @kerenlahav ,

We use crossplane to create CRs and we use multiple subaccounts in same cluster. So below is the current CR which works

kind: ServiceInstance
metadata:
  name: message-instance
  namespace: development
spec:
  serviceOfferingName: message-queuing
  servicePlanName: standard
  parameters:
    sourceIPs: 0.0.0.0/0
    resources:
      units: "100" 

Since Crossplane does not support creating CRs with namespace property ask is whether it can accommodated like below

kind: ServiceInstance
metadata:
  name: message-instance
spec:
  namespace: development 
  serviceOfferingName: message-queuing
  servicePlanName: standard
  parameters:
    sourceIPs: 0.0.0.0/0
    resources:
      units: "100"

[kerenlahav]

The example you specified actually means that a CR in namespace "default" should be treated like it was created in namespace "development", this contradicts the kubernetes/operator "contract".

You can have CRs for multiple subaccounts in one namespace by specifieng the secret name you want the operator to use, using the btpAccessCredentialsSecret property:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: sample-instance-1
spec:
  serviceOfferingName: service-manager
  servicePlanName: subaccount-audit
  btpAccessCredentialsSecret: subaccount1

each secret will contain credentials for a different subaccount.
note that all the referenced secrets must be located in the same namespace as the CRs.

[althaf1088]

The example you specified actually means that a CR in namespace "default" should be treated like it was created in namespace "development", this contradicts the kubernetes/operator "contract".

You can have CRs for multiple subaccounts in one namespace by specifieng the secret name you want the operator to use, using the btpAccessCredentialsSecret property:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: sample-instance-1
spec:
  serviceOfferingName: service-manager
  servicePlanName: subaccount-audit
  btpAccessCredentialsSecret: subaccount1

each secret will contain credentials for a different subaccount. note that all the referenced secrets must be located in the same namespace as the CRs.

ok will try referring the secret directly and will update

[althaf1088]

Hi @kerenlahav
I tried the above and was able to create serviceinstance referring the btpAccessCredentialsSecret only thing is it was expecting in sap-btp-service-operator namespace.

Searching for secret name sap-btp-service-operator-1 in namespace sap-btp-service-operator

But looks like we still cannot use it in Crossplane composition because the CRD is namespaced scope.

As mentioned here

So even if i leave the namespace empty and use btpAccessCredentialsSecret still due to crossplane limitation , i get the below error

an empty namespace may not be set when a resource name is provided

[kerenlahav]

about the btpAccessCredentialsSecret, you are right - it should be located in the management namespace as documented in the read me

When using kubectl, if namespace is not provided it defaults the "default" namespace, i'm not familiar with crossplane but according to the error you provided it does not seem to act the same, if namespaced resources are not supported than what you are looking for is a cluster resource which is not supported, you can raise a feature request here and it will be examined

[althaf1088]

Thanks. Yes to support crossplane composition , we will need a clusterscoped resource. Will raise a feature request. Thanks for your help