Hi Everybody, Quick question about initial organiz...
# gooddata-cn
Hi Everybody, Quick question about initial organization layout update through API in v2.0.1: • We’ve deployed it and got this response on …/layout/organization (host/id/name removed) • Then tried to put the 1.7 version org (filled clientid, clientsecret, issuerlocation for auth0 auth) with put but got:
Copy code
  "detail": "Client not found (0368cd3e-81dc-4b86-b032-1f78dca631c6)",
  "status": 400,
  "title": "Bad Request",
  "traceId": "22b785b8500a82a4"
What should I modify to be able to overwrite the previous client? Thanks
stacktrace from logs:
Copy code
"msg": "Bad Request",
        "exc": "errorType=com.gooddata.tiger.grpc.client.dex.pojo.ClientNotFoundException, message=Client not found (0368cd3e-81dc-4b86-b032-1f78dca631c6)\n\tat com.gooddata.tiger.grpc.client.dex.DexClient$deleteClient$6.invoke(DexClient.kt:171)\n\tat com.gooddata.tiger.grpc.client.dex.DexClient$deleteClient$6.invoke(DexClient.kt:166)\n\tat com.gooddata.tiger.grpc.client.dex.DexClient.postProcessOperation(DexClient.kt:206)\n\tat com.gooddata.tiger.grpc.client.dex.DexClient.deleteClient$suspendImpl(DexClient.kt:166)\n\tat com.gooddata.tiger.grpc.client.dex.DexClient$deleteClient$1.invokeSuspend(DexClient.kt)\n\tat kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)\n\tat
#gooddata-cn could you please check this? Unfortunately we’ve blocked by this now and quick solution would be needed
@Robert Moucha @Jan Soubusta Could you help me out here please?
When setting OAUTH client, we first try to delete the old client from DEX. If the delete fails, we log a message with reason, try to find the log record, it should contain the keyword
But it looks like it is caused by the client is not found in DEX, which means that DEX database is not in sync with the state of the organization.
Hello Zoltán, just a quick check - Are we talking about GoodData.CN Community Edition, or a full-blown kubernetes installation?
kube install
no additional message in the logs:
Copy code
  "log": "{\"ts\":\"2022-07-21 08:54:42.983\",\"level\":\"WARN\",\"logger\":\"com.gooddata.tiger.grpc.client.dex.DexClient\",\"thread\":\"http-nio-9007-exec-1\",\"traceId\":\"f6138efb0e4963e6\",\"spanId\":\"f6138efb0e4963e6\",\"userId\":\"admin\",\"orgId\":\"xpoint-gd\",\"msg\":\"\",\"action\":\"dex-delete-client\",\"id\":\"0368cd3e-81dc-4b86-b032-1f78dca631c6\",\"state\":\"failure\",\"detail\":\"client not found\"}\n",
  "stream": "stdout",
  "log_processed": {
    "ts": "2022-07-21 08:54:42.983",
    "level": "WARN",
    "logger": "com.gooddata.tiger.grpc.client.dex.DexClient",
    "thread": "http-nio-9007-exec-1",
    "traceId": "f6138efb0e4963e6",
    "spanId": "f6138efb0e4963e6",
    "userId": "admin",
    "orgId": "org",
    "msg": "",
    "action": "dex-delete-client",
    "id": "0368cd3e-81dc-4b86-b032-1f78dca631c6",
    "state": "failure",
    "detail": "client not found"
  "kubernetes": {
    "pod_name": "gooddata-cn-metadata-api-5b4fb99df8-dsk8l",
    "namespace_name": "gooddata-cn",
    "pod_id": "2a696f62-4191-40f6-85fa-d560fee3c21b",
    "host": "ip-10-0-5-98.us-west-2.compute.internal",
    "container_name": "metadata-api",
    "docker_id": "c8fdcc15417d298ee57f61017b49e5fe9d206ed9e6ac361fd8455e04cf230f60",
    "container_hash": "gooddata/metadata-api@sha256:2820f7f324d62019466caca16f7bcc36641d5812d85f9612860e3b3d305502e7",
    "container_image": "gooddata/metadata-api:2.0.1"
The only workaround solution I can see now is to log in directly to the Postgres instance (database MD), where we store all metadata including organization and update it to fix the inconsistency. Something like:
Copy code
update organization set oauth_client_id=X, .....
But maybe @Robert Moucha knows a better solution
anyway, in the meantime I redeployed it from-scratch and haven’t checked in the browser, just instantly add the new org yml with auth0 props and then it worked…but it’s weird, I experienced it before with a local docker run as well
log in directly to the Postgres instance
Yeah, I thought about it but I don’t have direct/opened connection access to the db right now
Hmm, so you were upgrading from 1.7 to 2.0.1, you're using internal dex AND built-in postgresql-ha subchart?. The upgrade path for this configuration is complex due to major version upgrade (https://support.gooddata.com/hc/en-us/articles/7742169522579-GoodData-CN-2-0-0-Release-Notes) Dex data are also stored in this database, but it doesn't explain why would this oauth client disappear.