libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

Corrections to HA Guide

Browse source 
Closes #29183

Signed-off-by: AndyMunro <amunro@redhat.com>
This commit is contained in:
AndyMunro 2024-04-30 17:45:58 -04:00 committed by Alexander Schwartz
parent b95b865c60
commit eb9b19abe9
6 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/guides/high-availability/bblocks-active-passive-sync.adoc
View file

@ -41,7 +41,7 @@ A synchronously replicated database across two sites.
== {jdgserver_name}
An {jdgserver_name} deployment which leverages the {jdgserver_name}'s Cross-DC functionality.
A deployment of {jdgserver_name} that leverages the {jdgserver_name}'s Cross-DC functionality.
*Blueprint:* <@links.ha id="deploy-infinispan-kubernetes-crossdc" /> using the {jdgserver_name} Operator, and connect the two sites using {jdgserver_name}'s Gossip Router.

6
docs/guides/high-availability/concepts-active-passive-sync.adoc
View file

@ -15,11 +15,11 @@ Use this setup to be able to fail over automatically in the event of a site fail
Two independent {project_name} deployments running in different sites are connected with a low latency network connection.
Users, realms, clients, offline sessions, and other entities are stored in a database that is replicated synchronously across the two sites.
The data is also cached in the {project_name} embedded {jdgserver_name} as local caches.
The data is also cached in the {project_name} Infinispan caches as local caches.
When the data is changed in one {project_name} instance, that data is updated in the database, and an invalidation message is sent to the other site using the replicated `work` cache.
Session-related data is stored in the replicated caches of the embedded {jdgserver_name} of {project_name}, and forwarded to the external {jdgserver_name}, which forwards information to the external {jdgserver_name} running synchronously in the other site.
As session data of the external {jdgserver_name} is also cached in the embedded {jdgserver_name}, invalidation messages of the replicated `work` cache are needed for invalidation.
Session-related data is stored in the replicated caches of the Infinispan caches of {project_name}, and forwarded to the external {jdgserver_name}, which forwards information to the external {jdgserver_name} running synchronously in the other site.
As session data of the external {jdgserver_name} is also cached in the Infinispan caches, invalidation messages of the replicated `work` cache are needed for invalidation.
In the following paragraphs and diagrams, references to deploying {jdgserver_name} apply to the external {jdgserver_name}.

2
docs/guides/high-availability/concepts-infinispan-cli-batch.adoc
View file

@ -19,7 +19,7 @@ For human interactions, the CLI shell might still be a better fit.
== Example
The following `Batch` CR takes an {jdgserver_name} site offline as described in the operational procedure <@links.ha id="operate-switch-over" />.
The following `Batch` CR takes a site offline as described in the operational procedure <@links.ha id="operate-switch-over" />.
[source,yaml,subs="+attributes"]
----

4
docs/guides/high-availability/connect-keycloak-to-external-infinispan.adoc
View file

@ -47,8 +47,8 @@ include::examples/generated/keycloak-ispn.yaml[tag=keycloak-ispn]
This is optional and it default to `11222`.
<3> The Secret `name` and `key` with the {jdgserver_name} username credential.
<4> The Secret `name` and `key` with the {jdgserver_name} password credential.
<5> The `spi-connections-infinispan-quarkus-site-name` is an arbitrary {jdgserver_name} site name which {project_name} needs for its embedded {jdgserver_name} deployment when a remote store is used.
This site-name is related only to the embedded {jdgserver_name} and does not need to match any value from the external {jdgserver_name} deployment.
<5> The `spi-connections-infinispan-quarkus-site-name` is an arbitrary {jdgserver_name} site name which {project_name} needs for its Infinispan caches deployment when a remote store is used.
This site-name is related only to the Infinispan caches and does not need to match any value from the external {jdgserver_name} deployment.
If you are using multiple sites for {project_name} in a cross-DC setup such as <@links.ha id="deploy-infinispan-kubernetes-crossdc" />, the site name must be different in each site.
</@tmpl.guide>

2
docs/guides/high-availability/deploy-infinispan-kubernetes-crossdc.adoc
View file

@ -137,7 +137,7 @@ kubectl -n {ns} create secret generic {ts-secret} \
+
NOTE: Keystore and Truststore must be uploaded in both {ocp} clusters.
. Create an {jdgserver_name} Cluster with Cross-Site enabled
. Create a Cluster for {jdgserver_name} with Cross-Site enabled
+
The {infinispan-operator-docs}#setting-up-xsite[Setting Up Cross-Site] documentation provides all the information on how to create and configure your {jdgserver_name} cluster with cross-site enabled, including the previous steps.
+

2
docs/guides/high-availability/partials/infinispan/infinispan-credentials.adoc
View file

@ -32,4 +32,4 @@ include::../../examples/generated/ispn-single.yaml[tag=infinispan-credentials]
kubectl create secret generic connect-secret --from-file=identities.yaml
----
+
Check https://infinispan.org/docs/infinispan-operator/main/operator.html#configuring-authentication[Configuring Authentication] documentation for more details.
Check the {infinispan-operator-docs}#configuring-authentication[Configuring Authentication] documentation for more details.