Not able to to deploy an application

[junoriosity]

As mentioned earlier (#4219) I deployed kubeapps with

kubectl apply -f https://get.pinniped.dev/v0.13.0/install-pinniped-concierge-crds.yaml
kubectl apply -f https://get.pinniped.dev/v0.13.0/install-pinniped-concierge-resources.yaml

cat <<EOF | kubectl apply -f -
kind: JWTAuthenticator
apiVersion: authentication.concierge.pinniped.dev/v1alpha1
metadata:
  name: jwt-authenticator
spec:
  issuer: https://my-auth.eu.auth0.com/
  audience: my-client-id
  claims:
    groups: groups
    username: email
EOF

cat <<EOF | kubectl apply -f -
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubeapps-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: test@test.com
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: kubeapps-operators
EOF

kubectl create ns kubeapps
helm install kubeapps bitnami/kubeapps --namespace kubeapps -f myvals.yaml 

where myvals.yaml is

useHelm3: true
authProxy:
  additionalFlags:
    - --oidc-issuer-url=https://my-auth.eu.auth0.com/ # Example: https://antoniogamez.eu.auth0.com/  # mind the last "/" character
  # If you are using a different ingress config, you might need to tweak these flags. More info in the "oauth2-proxy" official docs
    - --redirect-url=http://127.0.0.1:3000/oauth2/callback
    # - --cookie-domain=localhost
    # - --whitelist-domain=localhost
    # - --cookie-secure=false
  clientID: my-client-id
  clientSecret: my-client-secret
  cookieSecret: bm90LWdvb2Qtc2VjcmV0Cg==
  enabled: true
  provider: oidc

pinnipedProxy:
  enabled: true # if using Pinniped, you'll need to enable this option here
#  defaultAuthenticatorType: jwt
#  defaultAuthenticatorName: jwt-authenticator

clusters:
  - name: default
    apiServiceURL: https://... # impersonation proxy URL
    certificateAuthorityData: ... #  impersonation proxy CA
    pinnipedConfig:
      enabled: true

With this I can reach the catalog panel

But when I click on one (like airflow), I receive

Do you know how to fix that?

[absoludity]

Thanks @junoriosity , though I meant if you could create an issue, not a discussion (they're two different things on Github), since this one is actually an issue. I've created #4323 .

So after investigating, I found the problem: for historical reasons, by default Kubeapps determines which cluster in the config is the one on which Kubeapps is installed (and hence, the one where global package repositories are present), by checking for a cluster without an APIServiceURL. This is because, prior to using pinniped's impersonation proxy, this was always true. But when a setup requires pinniped's impersonation proxy, we end up setting the APIServiceURL for each cluster and so Kubeapps has no way to know which cluster is the one with the global package repositories.

For this reason, we introduced an extra field in the clusters config, isKubeappsCluster, to be able to identify unambiguously which cluster is the one on which Kubeapps is installed (if any - yes, there are situations where you may not target that cluster at all).

So the solution here is to set the isKubeappsCluster in your clusters config, as documented in the values.yaml.

[junoriosity]

Many thanks for your immediate reply. I used to set now

clusters:
  - apiServiceURL: https://... # impersonation proxy URL
    certificateAuthorityData: ... #  impersonation proxy CA
    isKubeappsCluster: true
    name: default
    pinnipedConfig:
      enabled: true

yet the error from above remains.

[junoriosity]

@absoludity I have to take back my last comment. I was running helm upgrade und I had delete kubeapps and reinstall it.

Again, many thanks for your help.:)

[junoriosity]

Ah, one more thing regarding the isKubeappsCluster field:

If I want to run kubeapps on cluster A, but then deploy only cluster B and C - how would I do that?

[absoludity]

Ah, one more thing regarding the isKubeappsCluster field:

If I want to run kubeapps on cluster A, but then deploy only cluster B and C - how would I do that?

In that case, you won't have cluster A listed in your clusters config, nor will any cluster be identified as the kubeapps cluster. If you see the issue above in that case (ie. the kubeapps-apis services is saying "requests for available packages on clusters other than "" is not supported"), then re-open the related issue that I created with those details please. The available package being requested from the client should not have the cluster set, in this case (AFAICT).

I did demo this exact setup over a year ago when TKG first had the separate management and workload clusters (so that Kubeapps could run on the management cluster with users only able to target workload clusters - see https://liveandletlearn.net/post/kubeapps-on-tkg-management-cluster/ ), but that was done before we migrated to the new kubeapps-apis service.