You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upon changing the name (first pulumi name/atribute) of the type ClientOptionalScopes, ClientDefaultScopes this lists two changes in pulumi. The changes are a create and a delete. As the delete runs after the create the delete supersedes leaving the client section blank.``
Expected Behavior
a change to this should be an update or replace and the client scopes contain the correct data.
Steps to reproduce
Create a client with and use either ClientOptionalScopes or ClientDefaultScopes
pulumi about
CLI
Version 3.65.1
Go Version go1.20.3
Go Compiler gc
Plugins
NAME VERSION
azure 5.42.0
azure-native 1.66.0
azuread 5.36.0
keycloak 5.1.0
mailgun 3.4.0
opsgenie 1.1.6
python unknown
random 4.8.0
Host
OS Microsoft Windows 11 Pro
Version 10.0.22621 Build 22621
Arch x86_64
This project is written in python: executable='[redacted]\Local\Microsoft\WindowsApps\python.exe' version='3.10.11
'
Current Stack: juriba/customer/rsdev
TYPE URN
[Stack info redacted]
Found no pending operations associated with [redacted]
Backend
Name pulumi.com
URL [redacted]
User [redacted]
Organizations [redacted]
Dependencies:
NAME VERSION
pip 23.0.1
pulumi-azure 5.42.0
pulumi-azure-native 1.66.0
pulumi-azuread 5.36.0
pulumi-keycloak 5.1.0
pulumi-mailgun 3.4.0
pulumi-opsgenie 1.1.6
pulumi-random 4.8.0
setuptools 67.6.0
wheel 0.40.0
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).
The text was updated successfully, but these errors were encountered:
This kind of change confuses Pulumi because it changes the Pulumi identity of the resource making the engine think it's operating on two distinct instances, but the instances actually resolve to the same instance in the upstream provider. IN the specs of the upstream provider realm_id and client_id are marked as ForceNew, and likely they actually identify the resource.
I'm not aware of an easy way for the pulumi-keycloak provider to fix this issue, but there is a workaround that may be applicable for your use case. Please look into using the aliases option to make Pulumi aware that your change renames an existing resource instead of creating a new one. This should generate an Update plan instead of Create+Delete and should work better.
I cant say this is an ideal solution as you then have to maintain that list of aliases. We use dynamic names for most of our resources so I feel like it may cause more problems.
I would mention that this issue seems to be present on a number of other resources too. I discovered the same issue with keycloak.GroupRoles this afternoon.
This is an instance of pulumi/pulumi#9925. We're looking into systematic fixes, but for now, users must be careful to avoid renaming resources with idempotent creates.
What happened?
Upon changing the name (first pulumi name/atribute) of the type
ClientOptionalScopes
,ClientDefaultScopes
this lists two changes in pulumi. The changes are a create and a delete. As the delete runs after the create the delete supersedes leaving the client section blank.``Expected Behavior
a change to this should be an update or replace and the client scopes contain the correct data.
Steps to reproduce
Create a client with and use either
ClientOptionalScopes
orClientDefaultScopes
Now change the name of
keycloak.openid.ClientDefaultScopes
tosecondname
Output of
pulumi about
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).
The text was updated successfully, but these errors were encountered: