Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Realm name cannot have more than 36 characters #675

Open
dmpv-cyber opened this issue Jan 29, 2025 · 11 comments
Open

Realm name cannot have more than 36 characters #675

dmpv-cyber opened this issue Jan 29, 2025 · 11 comments
Labels
kind/bug Some behavior is incorrect or out of spec needs-repro Needs repro steps before it can be triaged or fixed

Comments

@dmpv-cyber
Copy link

Describe what happened

When trying to create a new realm and if I define a realm prop bigger than 36 characters it will fail, because it will try to set the realm name also to the realm Id column on the database that has a limit of 36 characters.

Sample program

new Realm( 'name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm', { realm: 'name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa', })

Log output

error: sdk-v2/provider2.go:520: sdk.helper_schema: error sending POST request to /admin/realms: 409 Conflict. Response body: {"errorMessage":"Conflict detected. See logs for details"}: [email protected]
If I check the logs I have:
Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(36)

Affected Resource(s)

Realm

Output of pulumi about

Dependencies:
NAME VERSION
@pulumi/aws 6.66.2
@pulumi/awsx 2.19.0
@pulumi/keycloak 5.4.0
@pulumi/pulumi 3.144.1

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@dmpv-cyber dmpv-cyber added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Jan 29, 2025
@dmpv-cyber
Copy link
Author

dmpv-cyber commented Jan 29, 2025

There is another prop on the Realm constructor that could help solve this, internalId, when I set that prop to something that is less or equal to 36 characters long, for example an UUID, the name of the realm in that case can be bigger than 36 characters.
The first pulumi up is successful and I can see the created realm, however, when I try to do another pulumi up, with the same props defined, it will fail again with:
sdk-v2/provider2.go:520: sdk.helper_schema: error sending POST request to /admin/realms: 409 Conflict. Response body: {"errorMessage":"Conflict detected. See logs for details"}: [email protected]
and if I check the logs I can see this:
Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "constraint_4a"
It looks like it's trying to add another Realm with the same internalId I set whenever I do another pulumi up, here is an example of the details whenever I try that failing pulumi up:

++keycloak:index/realm:Realm: (create-replacement)
        [id=name-test]
        [urn=urn:pulumi:keycloak-configuration::keycloak::keycloak:index/realm:Realm::name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm]
        [provider=urn:pulumi:keycloak-configuration::keycloak::pulumi:providers:keycloak::default_5_4_0::afa176ec-9d8c-40f3-bd97-f6e0ee023a5e]
      ~ enabled    : false => true
      + internalId : "a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa"
      + sslRequired: "external"
    +-keycloak:index/realm:Realm: (replace)
        [id=name-test]
        [urn=urn:pulumi:keycloak-configuration::keycloak::keycloak:index/realm:Realm::name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm]
        [provider=urn:pulumi:keycloak-configuration::keycloak::pulumi:providers:keycloak::default_5_4_0::afa176ec-9d8c-40f3-bd97-f6e0ee023a5e]
      ~ enabled    : false => true
      + internalId : "a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa"
      + sslRequired: "external"

code used to reproduce the issue:

new Realm('name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm', {
          internalId: 'a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa',
          realm: 'name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm'
        })

@VenelinMartinov
Copy link
Contributor

Hi @dmpv-cyber sorry you had issues here. The problem looks like a wrong replacement decision on the second pulumi up.

To work around it, are you able to use ignoreChanges for the property causing the replacement? https://www.pulumi.com/docs/iac/concepts/options/ignorechanges/

The pulumi keycloak provider is based on the terraform keycloak provider. Can you try to reproduce the issue there and report it to the keycloak developers? https://github.com/keycloak/terraform-provider-keycloak

Let me know if that helps!

@VenelinMartinov VenelinMartinov added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Jan 29, 2025
@dmpv-cyber
Copy link
Author

dmpv-cyber commented Jan 29, 2025

Hi @VenelinMartinov Thank you for the response and the help provided!

The ignoreChanges does work but it's not really a work around because, this can only be used if the resource was created a first time without that ignoreChanges set, on the second time we do a pulumi up and if we add that to the resource then all is good and it works.
However, if the ignoreChanges is set on the resource the first time we run it, we will run into the same issue ,and it will try to update the internalId.

I did try to reproduce this error on terraform-keycloak-provider, but I was unable, it looks like all is good and working as intended, here is a sample of what I used to test this on terraform:

terraform {
  required_providers {
    keycloak = {
      source  = "keycloak/keycloak"
      version = ">= 5.0.0"
    }
  }
}

provider "keycloak" {
  client_id     = "pulumi"
  client_secret = "client_secret"
  url           = "http://localhost:8080"
}

resource "keycloak_realm" "test" {
  internal_id       = "2bbe52b2-ca88-4220-b926-26b27a2525e5"
  realm             = "test-2bbe52b2-ca88-4220-b926-26b27a2525e5"
  enabled           = true
  display_name      = "Test"
}

So, not sure if this an issue from pulumi-keycloak? I also noticed there are some more props on the realm resource that are marked with a replacement decision but they shouldn't be on the second time we do the pulumi up, for example:
internationalization,accessTokenLifespan,accountTheme,attributes,emailTheme,enabled
just to name a few.

Thanks again for the answer and the time spent looking at this 😄

@pulumi-bot pulumi-bot added needs-triage Needs attention from the triage team and removed awaiting-feedback Blocked on input from the author labels Jan 29, 2025
@VenelinMartinov
Copy link
Contributor

Hey @dmpv-cyber

Can you please run pulumi preview --diff --refresh and see if the issue reproduces?

Looking at your terraform code you are specifying enabled=True there but not in your pulumi program, does that make a difference?

Does the terraform issue reproduce if you run it with terraform apply -refresh=false? One difference between TF and pulumi is that TF refreshes by default while Pulumi doesn't.

@VenelinMartinov VenelinMartinov added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Jan 31, 2025
@dmpv-cyber
Copy link
Author

Thank you again for the time that you took looking into this @VenelinMartinov

I tried running pulumi preview --diff --refresh and the issue still reproduces, it tries to do the same changes as if we use just the pulumi preview command.

You are right about the enabled=True I also did set this on my pulumi code, but that does not seem to make any difference, on the second pulumi preview it also tries to change the enabled from false to true, even though it's already set to true, this happens also with the pulumi preview --diff --refresh command.

About this command terraform apply -refresh=false I tried it on my terraform code and, after running the issue did not reproduce as on pulumi, it does not try to update anything.

I have not really a good ideia of what can be the issue here, but maybe it's not connected with the refresh stack?

@pulumi-bot pulumi-bot added needs-triage Needs attention from the triage team and removed awaiting-feedback Blocked on input from the author labels Feb 4, 2025
@VenelinMartinov
Copy link
Contributor

VenelinMartinov commented Feb 4, 2025

@dmpv-cyber I tried to repro the problem and program worked fine for me and showed no diff on the second pulumi up. I tried with

import * as keycloak from "@pulumi/keycloak";

new keycloak.Realm('name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm', {
          internalId: 'a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa',
          realm: 'name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm'
        })

and ran:

  1. pulumi up --yes
  2. pulumi preview --diff

Can you please upgrade your keycloak provider to the latest version (6.4.0) and try again. If that does not work, please post:

  1. The exact program you tried.
  2. Step by step instructions on how to reproduce it.
  3. Output of pulumi about
  4. Output of running your pulumi commands with the environment variable PULUMI_DEBUG_GPRC="grpc.json"

@VenelinMartinov VenelinMartinov added needs-repro Needs repro steps before it can be triaged or fixed awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Feb 4, 2025
@dmpv-cyber
Copy link
Author

dmpv-cyber commented Feb 4, 2025

@VenelinMartinov I used exactly the same code as you used this time around the only difference being on the keycloak provider version as I used the latest one I have available (6.3.0-alpha.1738648261) instead of (6.4.0) and encountered the same issue, ran:

  1. pulumi up --yes
  2. pulumi preview --diff

Output of pulumi about:

CLI
Version 3.147.0
Go Version go1.23.5
Go Compiler gc
Plugins
KIND NAME VERSION
language nodejs 3.147.0-dev.0
Host
OS darwin
Version 15.2
Arch arm64
This project is written in nodejs: executable='/opt/homebrew/bin/node' version='v23.2.0'
Current Stack: pulumi-keycloak-test
TYPE URN
pulumi:pulumi:Stack urn:pulumi:pulumi-keycloak-test::pulumi:pulumi:Stack::pulumi-keycloak-test
pulumi:providers:keycloak urn:pulumi:pulumi-keycloak-test::pulumi:providers:keycloak::default_6_3_0_alpha_1738648261
keycloak:index/realm:Realm urn:pulumi:pulumi-keycloak-test::keycloak:index/realm:Realm::name-a9c1ae55-6f5b-49de-8ef0-952a6c9c33aa-realm
Found no pending operations associated with pulumi-keycloak-test
Backend
Name
URL
User
Organizations
Token type personal

Output of running pulumi commands with the environment variable PULUMI_DEBUG_GPRC="grpc.json":

test.json

@pulumi-bot pulumi-bot added needs-triage Needs attention from the triage team and removed awaiting-feedback Blocked on input from the author labels Feb 4, 2025
@VenelinMartinov
Copy link
Contributor

My bad, for the provider version I meant 6.2.1.

What is the version of keycloak you are using? Looking at the logs it seems the provider is not responding correctly to the request to set the internal ID. It might be that your version doesn't support that parameter. Can you try upgrading that?

@VenelinMartinov VenelinMartinov removed the needs-triage Needs attention from the triage team label Feb 4, 2025
@dmpv-cyber
Copy link
Author

dmpv-cyber commented Feb 4, 2025

No worries @VenelinMartinov, I switched the provider to 6.2.1 and it happens the same.

I'm using the latest keycloak version (26.1.0) was this provider already tested against the latest version of keycloak?
Tried already with version 26.0.8 of keycloak and it happens the same 🤔

@VenelinMartinov
Copy link
Contributor

Yeah, I tested on the latest version too (26.1.0).

Can you please try this with a fresh keycloak instance? It could be some difference in the instance configuration perhaps?

I used https://www.keycloak.org/getting-started/getting-started-docker for running the instance and authenticated via a username and password.

@dmpv-cyber
Copy link
Author

@VenelinMartinov I think I might have found the issue.

I tried all the same things as before but this time instead of using the authentication via client credentials grant I used the same as you, via password grant and it did work, the second pulumi diff did not have any changes so, maybe you can reproduce the issue on your end if you try to use the client credentials grant as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec needs-repro Needs repro steps before it can be triaged or fixed
Projects
None yet
Development

No branches or pull requests

3 participants