To GoodData homepage
Solved

How to verify GoodData.CN installation on AWS EKS?

  • 20 February 2024
  • 22 replies
  • 144 views
D
  • dlu
  • Participating Frequently
  • 14 replies

Hi. We are evaluating the possibility of hosting GoodData.CN on AWS EKS ourselves. I have tried to follow the instructions on https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/ as close as I can, while deviating “a little” when it did not work.

I have tried the simple cases without many things in https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/considerations/, like DNS or TLS configurations. I am trying to get a simple case working and then possibly adding those considerations later.

Here are my steps

  1. Created an AWS EKS cluster
    1. Kubernetes 1.28
    2. 4 AvailabilityZones
    3. 6 t3.large instances
  2. Installed Kubernetes Dashboard
  3. Installed AWS Load Balancer Controller following instructions on https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html. Verified by installing https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.1/docs/examples/2048/2048_full.yaml
  4. For Nginx Ingress Controller, I followed https://aws.amazon.com/blogs/containers/exposing-kubernetes-applications-part-3-nginx-ingress-controller/, the “Usage with AWS Load Balancer Controller” section such that it created an internet-facing AWS Load Balancer. Verified that the DNS of the load balancer works with examples on that page.
  5. Enabled Dynamic Volume Provisioning
  6. Installed Apache Pulsar with Helm. Not custom values. Verified via port-forwarding.
  7. Skipped Redis and Aurora since it seems GoodData.CN has Redis and Postgres by default.
  8. Installed GoodData.CN version 3.3.1 using Helm. Customizations:
    1. License key.
    2. metadataApi.encryptor.enabled = false.

Up to this point, everything seems to be working. Kubernetes Dashboard shows everything green. All persistent volumes have been created.

Now how do I verify if the installation is successful?

One thing I have to mention is that the license key I am using is the one we got for GoodData.CN “Container” edition. Does it work here? Does it affect the installation or the steps below?

Assuming the license works for Kubernetes edition, I followed https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/set-up-organizations/setup-organizations/ and created an organization, but I don’t really see the impact on the Kubernetes cluster.

The next step is to set up Authentication, which involves $HOST_URL, but I am not sure what that is. Is it the load balancer DNS for Nginx Ingress Controller? In EKS, I see an ingress called “gooddata-cn-dex” with a path to “/dex”, should there be another ingress for “/api”?

Thanks in advance.

icon

Best answer by Jan Kos 6 March 2024, 15:44

View original

22 replies

Jan Kos
Rank
Userlevel 2

Hello,

GoodData CN.CE license works solely with the Container Edition of CN application - https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/community-edition/. Running k8s/Helm version of CN application requires dedicated license. I’ve already highlighted your question to your Account Owner to discuss with you what are your options.

In theory you should be able to install k8s application together with third party systems (Pulsar, Nginx). But without a valid license, API would throw errors. 

As you describing, assuming installing the GoodData.CN with helm went without errors? After the instalation, there should be various CN services pods running in gooddata-cn namespace. Are there any pods that are not up and running?

Was there any errors during creating an organization? You can check if the organization is created by running

kubectl -n gooddata-cn get org

and creating organization should as well create an ingress resource according to configuration.

$HOST_URL should be the hostname you specified in your-org-definition.yaml during org creation.

 

But again to be able to run GD.CN in kubernetes, you’ll need to have a dedicated license which is being handled you your account owner.

Jan

D

Hi Jan,

Thanks for the response. Yes, I suspect that license won’t work, and we will work it out. I just want to test the installation first.

In terms of installation, everything seems to be working fine. See attached.

kubectl -n gooddata-cn get org
NAME          ID        NAME             HOSTNAME
my-org        xxx       xxx             x.y.example.com

I have installed an org, so you are saying $HOST_URL should be http://x.y.example.com? I tried it with curl on my PC, and it could not resolve the host. 

  1. Is that hostname relative to inside the kubenetes cluster? 
  2. How do I access it via the AWS load balancers I set up in steps 3 and 4 in the original post? 
  3. I see an ingress named “gooddata-cn-dex”. How do I access it? What APIs can I use to test the connectivity?
  4. Should there be other ingresses for “/api”?

Thanks.

1 Attachment
D

Hi. I went through the https://university.gooddata.com/first-steps-with-gooddatacn course, but those are about the use of GoodData on the website. Is there any course or tuturial about its adminstration on the backend? 

There are many gooddata-cn pods in the cluster, and what would be the basic steps to check? I can get into a pod with "kubectl exec -it -n gooddata-cn <pod_id> -- /bin/bash" command. Could you give me some CLI commands for some pods?

Jan Kos
Rank
Userlevel 2

HOSTNAME in your created organization (“x.y.example.com” in this case) needs to be a fully qualified hostname, it needs to be resolvable and accessed from the internet. It is the entry point where the whole CN application is available.

The hostname should have DNS record pointing to public facing IPs of your load balancer serving as an entry point to the kubernetes cluster. You would need to decide how you’ll be handling DNS records - you either manage DNS manually completely on your side or you can manage DNS with “external-dns”. For example, internally we are using Route 53 service on AWS. Please review - https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/considerations/dns-configuration/

Together with is you’ll need to set up TLS configuration and certificates. Please refer to deployment considerations - especially “Domains and Certificates Management”, “TLS Configuration”, “Cert-manager Integration with Let's Encrypt” pages.

However for a quick test and verification of the installation the above can be skipped and use some online tool (e.g. nip.io) to make the load balancers public IP a qualified hostname which can be resolved in browser. Then assign this address as a HOSTNAME to an organization.

Assuming the above would be sorted out, authentication needs to be set up. You can either use dex (not recommended for production) which is deployed within CN application when installing GoodData with Helm or use your own Identity provider.

For dex you’ll need to set authentication hostname (can be done by appending auth. at the beginning of the HOSTNAME of an organization) and provide it in “customized-values-gooddata-cn.yaml” during helm install or updated by helm upgrade - https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/helm-chart-installation/#HelmChartInstallation-InternalOIDCidentityprovidersettings

dex:
  ingress:
    authHost: 'auth.company.com'
    tls:
      authSecretName: gooddata-cn-auth-tls

tls and annotations sections can be skipped if you are just quickly testing and not setting up tls. If skipped you might need to add 

# file ingress-values.yaml
controller:
  config:
    force-ssl-redirect: "true"
    use-forwarded-headers: true

to the ingress-values.yaml file together with AWS considerations and update ingress with helm update command to handle potential issues with http/https. And then to follow to create a user.

Jan Kos
Rank
Userlevel 2

Unfortunately, we don’t have any tutorials on university about GoodData.CN backed management or installation. We have deployment architecture page to describe individual services a bit closer and the section about GoodData.CN you were already exploring.
Checking GoodData specific pods in the kubernetes cluster wouldn’t differ from checking any other pods running in kubernetes. Widely used tool is kubectl and for example 

kubectl describe pod -n <namespace> <pod-name>

would give you some pod’s status, events, errors within k8s infrastructure, or 

kubectl logs <pod-name>

to get pod’s logs.

Standard tools and commands for managing k8s cluster would apply.

D

Thanks for the answers. I need to digest.

But quickly, when I installed nginx-ingress-controller, an AWS Load Balancer was created and can be accessed from internet with its DNS name. Are you saying that I should use this DNS when creating the org?

How is this load balancer, created before GDCN installation, get routed to GDCN? I was expecting some ingress definition, but did not see it in the cluster except “gooddata-cn-dex”.

Thanks.

Jan Kos
Rank
Userlevel 2

Yes, DNS should be used when creating org. as it is the access point to CN application. When creating an organization, the organization controller will create the org itself and creating an org should as well create a corresponding ingress. Can you check if ingress corresponding to created organization is present? e.g. with 

kubectl get ingress -A

 

D

Hi Jan,

Thanks for the response. Here is the list of all ingresses in the cluster.

kubectl get ingressclass -A
NAME    CONTROLLER             PARAMETERS   AGE
alb     ingress.k8s.aws/alb    <none>       3d22h
nginx   k8s.io/ingress-nginx   <none>       3d20h


kubectl get ingress -A
NAMESPACE     NAME              CLASS   HOSTS       ADDRESS                                                                   PORTS   AGE
apps          first-ingress     nginx   *           3.227.244.190                                                             80      3d19h
game-2048     ingress-2048      alb     *           k8s-game2048-ingress2-a72418af39-1957947424.us-east-1.elb.amazonaws.com   80      3d22h
gooddata-cn   gooddata-cn-dex   nginx   localhost   3.227.244.190                                                             80      3d13h

In my original post, in step 3, I installed AWS Load Balancer Controller following instructions on https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html. Verified by installing https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.1/docs/examples/2048/2048_full.yaml. That "ingress-2048" in "game-2048" namespace corresponds to this step.

In step 4, for Nginx Ingress Controller, I followed https://aws.amazon.com/blogs/containers/exposing-kubernetes-applications-part-3-nginx-ingress-controller/, the “Usage with AWS Load Balancer Controller” section such that it created an internet-facing AWS Load Balancer. Verified that the DNS of the load balancer works with examples on that page. The "first-ingress" in "apps" namespace is the testing

In the post, section "Exposing NGINX Ingress Controller via a Load Balancer", it listed 3 options: 2 "In-tree Service Controllers", "AWS Classic Load Balancer" and "AWS Network Load Balancer", and "Usage with AWS Load Balancer Controller". I followed the “Usage with AWS Load Balancer Controller” with the following configuration
 

controller:
  service:
    type: LoadBalancer
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-name: gooddata-cn-nginx-aws-ingress
      service.beta.kubernetes.io/aws-load-balancer-type: external
      service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
      service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: http
      service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthz
      service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: 10254

So it created an AWS Load Balancer "gooddata-cn-nginx-aws-ingress", and its DNS is "gooddata-cn-nginx-aws-ingress-95f3efe87e446ba3.elb.us-east-1.amazonaws.com". It is open to public and "http://gooddata-cn-nginx-aws-ingress-95f3efe87e446ba3.elb.us-east-1.amazonaws.com/first" returns a response "first".

Is my installation of "Nginx Ingress Controller" a problem? 

D

After our discussion on DNS names, I recreated the org, and the HOSTNAME now is the DNS

kubectl -n gooddata-cn get org
NAME  ID      NAME   HOSTNAME
xxx   xxx     xxx    gooddata-cn-nginx-aws-ingress-95f3efe87e446ba3.elb.us-east-1.amazonaws.com

I tried to follow https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/set-up-authentication/built-in-oidc/ to get a list of users

curl -H "Authorization: Bearer $BOOTSTRAP_API_TOKEN" \
     -H "Content-type: application/json" --request GET\
     $HOST_URL/api/v1/auth/users

But what is $BOOTSTRAP_API_TOKEN? How is it related to the orgnization? Is it the "adminUserToken"? I tried it and it returned 404 Not Found.

curl -H "Authorization: Bearer <org adminUserToken>" -H "Content-type: application/json" --request GET  http://gooddata-cn-nginx-aws-ingress-95f3efe87e446ba3.elb.us-east-1.amazonaws.com/api/v1/auth/users/
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

Of course, if the ingress is not set up correctly, this may be the correct answer.

As always, thanks for your help

D

Since you mentioned "the organization controller", I checked the logs of the two controller pods. One of them repeats the following error.

[2024-02-23 07:21:04,176] kopf.objects         [INFO    ] name=xxx-yyy-org k8sType=organizations action=createOrg state=start 
[2024-02-23 07:21:04,189] kopf.objects         [INFO    ] name=xxx-yyy-org k8sType=organizations action=orgSpec id=xxx-yyy adminGroup=adminGroup adminUser=admin hostname=gooddata-cn-nginx-aws-ingress-95f3efe87e446ba3.elb.us-east-1.amazonaws.com entitlements=[]
[2024-02-23 07:21:04,207] kopf.objects         [INFO    ] name=xxx-yyy-org k8sType=organizations action=metadataOrgUpdate state=start 
[2024-02-23 07:21:04,309] kopf.objects         [INFO    ] name=xxx-yyy-org k8sType=organizations action=metadataOrgUpdate durationMillis=100 state=finished 
[2024-02-23 07:21:04,310] kopf.objects         [INFO    ] name=xxx-yyy-org k8sType=organizations action=createIngress state=start 
[2024-02-23 07:21:04,443] kopf.objects         [ERROR   ] name=xxx-yyy-org k8sType=organizations action=createOrg durationMillis=267 message=admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the Ingress administrator state=error 
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pykube/http.py", line 438, in raise_for_status
    resp.raise_for_status()
  File "/usr/local/lib/python3.11/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://10.100.0.1:443/apis/networking.k8s.io/v1/namespaces/gooddata-cn/ingresses

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/app/gd_logging.py", line 132, in wrapper
    func_output = func(*args, **kwargs)
                  ^^^^^^^^^^^^^^^^^^^^^
  File "/app/controller.py", line 396, in create_fn
    create_ingress(org_logger, body, name)
  File "/app/gd_logging.py", line 138, in wrapper
    raise e
  File "/app/gd_logging.py", line 132, in wrapper
    func_output = func(*args, **kwargs)
                  ^^^^^^^^^^^^^^^^^^^^^
  File "/app/controller.py", line 286, in create_ingress
    ingress_obj.create()
  File "/usr/local/lib/python3.11/site-packages/pykube/objects.py", line 131, in create
    self.api.raise_for_status(r)
  File "/usr/local/lib/python3.11/site-packages/pykube/http.py", line 445, in raise_for_status
    raise HTTPError(resp.status_code, payload["message"])
pykube.exceptions.HTTPError: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the Ingress administrator
[2024-02-23 07:21:04,453] kopf.objects         [ERROR   ] Handler 'create_fn' failed with an exception. Will retry.
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pykube/http.py", line 438, in raise_for_status
    resp.raise_for_status()
  File "/usr/local/lib/python3.11/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://10.100.0.1:443/apis/networking.k8s.io/v1/namespaces/gooddata-cn/ingresses

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/kopf/_core/actions/execution.py", line 276, in execute_handler_once
    result = await invoke_handler(
             ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/kopf/_core/actions/execution.py", line 371, in invoke_handler
    result = await invocation.invoke(
             ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/kopf/_core/actions/invocation.py", line 139, in invoke
    await asyncio.shield(future)  # slightly expensive: creates tasks
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/gd_logging.py", line 138, in wrapper
    raise e
  File "/app/gd_logging.py", line 132, in wrapper
    func_output = func(*args, **kwargs)
                  ^^^^^^^^^^^^^^^^^^^^^
  File "/app/controller.py", line 396, in create_fn
    create_ingress(org_logger, body, name)
  File "/app/gd_logging.py", line 138, in wrapper
    raise e
  File "/app/gd_logging.py", line 132, in wrapper
    func_output = func(*args, **kwargs)
                  ^^^^^^^^^^^^^^^^^^^^^
  File "/app/controller.py", line 286, in create_ingress
    ingress_obj.create()
  File "/usr/local/lib/python3.11/site-packages/pykube/objects.py", line 131, in create
    self.api.raise_for_status(r)
  File "/usr/local/lib/python3.11/site-packages/pykube/http.py", line 445, in raise_for_status
    raise HTTPError(resp.status_code, payload["message"])
pykube.exceptions.HTTPError: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the Ingress administrator

Looks like it is related to my installation of “Nginx Ingress Controller”. I will wait for your confirmation and detailed instructions.

Jan Kos
Rank
Userlevel 2

Hello,

So far, I can’t tell if there is a problem with nginx ingress controller but after a quick review of details provided, I don’t see any significant issues. 

But it looks like the ingress resource for the new organization didn’t get created, thus the 404 response. The ingress resource should be automatically created together with creating a new organization. Could you please let me know what steps did you take to recreate the organization? Might be worth checking the organization controller pods logs if there are some details regarding org. creation.

Could you also please provide

$BOOTSTRAP_API_TOKEN is a master token letting you access API resources. It needs to be created after CN application installation and it is described here - https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/set-up-authentication/bootstrap-token/

The bootstrap token is basically constructed as <adminUser>:bootstrap:<adminPassword> string and then base64 encoded.
adminUser and adminPassword are values used in custom-values.yaml file during CN application installation.

D

Hi Jan. Thanks for the response. Sorry I could not respond sooner as my computer got replaced, and I am still in the process getting everything in order.

One thing though. I did post another long message last Friday, but once I posted it, the content did NOT show, instead, a message was displayed, to the effect that the administrator of the site will examine the message and decide if it would be posted. Apparently it was gone.

Last Friday, I did notice error messages in the logs of “organization-controller”. I will try to get that and the information you asked today.

Thanks

D

Hi Jan,

Today, I deleted the cluster and redid all the steps, but got the same result. I zipped up the custom values files for installation of gooddata-cn and the organization, as well as the log from one of the organization-controller in the attached zip file.

What pops up to me are the following lines in the log:

[2024-02-28 02:47:54,407] kopf.objects         [ERROR   ] name=abc-hi-org k8sType=organizations action=createOrg durationMillis=1437 message=admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the 

requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://10.100.0.1:443/apis/networking.k8s.io/v1/namespaces/gooddata-cn/ingresses

pykube.exceptions.HTTPError: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the Ingress administrator

Can you shed light on what it means and what I need to do to fix it? Thanks.

1 Attachment
D

I just posted my findings today, and got the following message shown in the attached image, same as what I got on Friday. Not sure what is going on. Hope you can dig it out and see my postings. 

 

D

Hi Jan,

I am repositing parts of my original, in case you cannot find the zip file.

Today, I deleted the cluster and redid all the steps, but got the same result. What pops up to me are the following lines in the log:

[2024-02-28 02:47:54,407] kopf.objects         [ERROR   ] name=abc-hi-org k8sType=organizations action=createOrg durationMillis=1437 message=admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the 

requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https: //10.100.0.1:443/apis/networking.k8s.io/v1/namespaces/gooddata-cn/ingresses

pykube.exceptions.HTTPError: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the Ingress administrator

Can you shed light on what it means and what I need to do to fix it? Thanks.

D

Jan, any thought?

Jan Kos
Rank
Userlevel 2

Hi,

I’m sorry, I was on vacation, let me review the provided details and I’ll get back to you as soon as possible.

Jan

D

Got it, Jan. Hope you had a wonderful vacation. Looking forward to your response.

Jan Kos
Rank
Userlevel 2

 Hi,

I located your messages, it was automatically marked as spam. I unmarked it and the messages appeared in the thread above.

Thank you for the error message and logs. Are you using custom-snippet annotation somewhere? The error message:

[ERROR   ] name=xxx-yyy-org k8sType=organizations action=createOrg durationMillis=267 message=admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/configuration-snippet annotation cannot be used. Snippet directives are disabled by the Ingress administrator state=error

Means that creating ingress resource for organization could not be created because snippet annotations are not allowed by default. You can try to remove “nginx.ingress.kubernetes.io/configuration-snippet” annotation if you are using it somewhere or snippet annotations needs to be explicitly enabled in ingress nginx deployment e.g. by adding:

values:
    controller:
      allowSnippetAnnotations: true

If the suggestion doesn’t work would you mind sharing configuration of nginx ingress controller in yaml file?

D

Hi Jan,

Frankly, I don't know what snippet is in Nginx Ingress Controller, but your suggestion worked. I deleted Nginx Ingress Controller and GDCN, added "allowSnippetAnnotations: true" to the values.yaml for Nginx Ingress Controller, and reinstalled the Nginx Ingress Controller and GDCN. When I created the org, everything worked fine and an ingress called "managed-<org_name>" is created. I can then create and list users in DEX as instructed on https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/set-up-authentication/built-in-oidc/, using the DNS name of the load balancer when Nginx Ingress Controller is installed.

I was also able to load the login page at https://aws-nlb-nginx-ingress-ae2f4016a1575da4.elb.us-east-1.amazonaws.com/dex/auth/local/login?back=&state=wrusuapx3smfr7lvreyh37ln6. When I entered a wrong credential, the page displays "Invalid Email Address and password". When I entered the email and password using the user created above, I got,

Chrome Developer Tools shows the first error is a GET to https://aws-nlb-nginx-ingress-ae2f4016a1575da4.elb.us-east-1.amazonaws.com/api/v1/profile, resulting in

{
    "title": "Not Found",
    "status": 404,
    "detail": "404 NOT_FOUND \"User is not registered\"",
    "traceId": "263eda1e6e3f80d4"
}

The auth-service log shows

{"ts":"2024-03-07 21:21:21.404",
"level":"ERROR",
"logger":"com.gooddata.tiger.grpc.client.metadata.MetadataStoreClient",
"thread":"DefaultDispatcher-worker-2",
"msg":"getUserByAuthenticationId",
"action":"grpcClientCall",
"exc":"errorType=com.gooddata.tiger.common.exception.NotFoundException,
 message=No user found for authentication id CiRmODcxMWEzMi04ZmExLTQ4NmYtYTMwMC1kZDczMzZmYWRmMzISBWxvY2Fs
    at com.gooddata.tiger.grpc.error.ExceptionsKt.buildClientException(Exceptions.kt:35)
    at com.gooddata.tiger.grpc.error.ErrorPropagationKt.convertFromKnownException(ErrorPropagation.kt:252)
    at com.gooddata.tiger.grpc.error.ErrorPropagationKt.convertToTransferableException(ErrorPropagation.kt:218)
    at com.gooddata.tiger.grpc.error.ErrorPropagationKt.clientCatching(ErrorPropagation.kt:65)
    at com.gooddata.tiger.grpc.error.ErrorPropagationKt$clientCatching$1.invokeSuspend(ErrorPropagation.kt)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:33)
    at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
"}

1. We still don't have the correct license yet, and we are still working on getting one. But is this error related to the license?
2. If not, why is the user not found? 

Thank you very much for your help.

Jan Kos
Rank
Userlevel 2

Hmm, without a valid license, I would rather expect a 403 response when calling the CN apis. Did creating a user went through fine with the call from the documentation?

curl -H "Authorization: Bearer $BOOTSTRAP_API_TOKEN" \
     -H "Content-type: application/json" -d '{"email": "boss@alpha.example.com",
     "password": "123456", "displayName": "John Doe"}' --request POST \
     $HOST_URL/api/v1/auth/users

And did you received a valid response as indicated in the doc page? e.g.

{
  "email": "boss@alpha.example.com",
  "password": null,
  "displayName": "John Doe",
  "authenticationId": "CiQ0YWFiZmIzNy03MTNiLTQyNWYtODZhMy0yNmFlNmM1ZjYwNDMSBWxvY2Fs"
}

If the above went fine the next step is to map the user to the organization as outlined in the doc page earlier.

It leads to https://www.gooddata.com/docs/cloud-native/3.3/manage-organization/set-up-authentication/#map-users-to-the-organization page and the value of authenticationId received is used to map the user to the organization.

"404 NOT_FOUND \"User is not registered\"" error could mean that the user is not properly mapped.

Have you done this step as well?

D

Hi Jan,

I read https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/set-up-authentication/built-in-oidc/ many times, but I missed the section you pasted. Once I mapped the user, everything seems to work well. 

Thank you very much for helping me figure out the issues along the way. At least I have a working installation as my starting point to add other features. We can close this ticket.

Thanks again.

Reply


Join us on
Welcome to the GoodData Community!Cookie settings