Update migration and upgrade guides about GroupRemovedEvent no longer fired when removing a realm
Closes #30919 Signed-off-by: Pedro Igor <pigor.craveiro@gmail.com>
This commit is contained in:
parent
94934d1ad4
commit
1a8075d62a
2 changed files with 19 additions and 0 deletions
|
@ -23,6 +23,14 @@ Consequently, all caches are cleared when upgrading to this version.
|
||||||
|
|
||||||
Infinispan Protostream is based on https://protobuf.dev/programming-guides/proto3/[Protocol Buffers] (proto 3), which has the advantage of backwards/forwards compatibility.
|
Infinispan Protostream is based on https://protobuf.dev/programming-guides/proto3/[Protocol Buffers] (proto 3), which has the advantage of backwards/forwards compatibility.
|
||||||
|
|
||||||
|
= Group-related events no longer fired when removing a realm
|
||||||
|
|
||||||
|
With the goal of improving the scalability of groups, they are now removed directly from the database when removing a realm.
|
||||||
|
As a consequence, group-related events like the `GroupRemovedEvent` are no longer fired when removing a realm.
|
||||||
|
|
||||||
|
For information on how to migrate, see the link:{upgradingguide_link}[{upgradingguide_name}].
|
||||||
|
|
||||||
|
|
||||||
= Keycloak CR supports standard scheduling options
|
= Keycloak CR supports standard scheduling options
|
||||||
|
|
||||||
The Keycloak CR now exposes first class properties for controlling the scheduling of your Keycloak Pods.
|
The Keycloak CR now exposes first class properties for controlling the scheduling of your Keycloak Pods.
|
||||||
|
|
|
@ -21,6 +21,17 @@ This is an optimization to reduce traffic and network related resources.
|
||||||
In {project_name} 26, the new method has a default implementation to keep backward compatibility with custom implementation.
|
In {project_name} 26, the new method has a default implementation to keep backward compatibility with custom implementation.
|
||||||
The default implementation performs a single network call per an event, and it will be removed in a future version of {project_name}.
|
The default implementation performs a single network call per an event, and it will be removed in a future version of {project_name}.
|
||||||
|
|
||||||
|
= Group-related events no longer fired when removing a realm
|
||||||
|
|
||||||
|
With the goal of improving the scalability of groups, they are now removed directly from the database when removing a realm.
|
||||||
|
As a consequence, group-related events like the `GroupRemovedEvent` are no longer fired when removing a realm.
|
||||||
|
|
||||||
|
If you have extensions handling any group-related event when a realm is removed, make sure to use the `RealmRemovedEvent` instead
|
||||||
|
to perform any cleanup or custom processing when a realm, and their groups, are removed.
|
||||||
|
|
||||||
|
The `GroupProvider` interface is also updated with a new `preRemove(RealmModel)` method to force implementations to properly
|
||||||
|
handle the removal of groups when a realm is removed.
|
||||||
|
|
||||||
= Operator scheduling defaults
|
= Operator scheduling defaults
|
||||||
|
|
||||||
Keycloak Pods will now have default affinities to prevent multiple instances from the same CR from being deployed on the same node, and all Pods from the same CR will prefer to be in the same zone to prevent stretch cache clusters.
|
Keycloak Pods will now have default affinities to prevent multiple instances from the same CR from being deployed on the same node, and all Pods from the same CR will prefer to be in the same zone to prevent stretch cache clusters.
|
||||||
|
|
Loading…
Reference in a new issue