Fix product name usage for downstream documentation
Closes #29154 Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
Alexander Schwartz
Alexander Schwartz
parent
51352622aa
commit
99cb437dc7
9 changed files with 16 additions and 16 deletions
|
|
@ -49,6 +49,6 @@ NOTE: Modifying a `Batch` CR instance has no effect. Batch operations are "`one-
|
|||
|
||||
== Further reading
|
||||
|
||||
For more information, see the link:{infinispan-operator-docs}#batch-cr[{jdgserver_name} Operator Batch CR documentation].
|
||||
For more information, see the link:{infinispan-operator-docs}#batch-cr[{jdgserver_name} Operator `Batch` CR documentation].
|
||||
|
||||
</@tmpl.guide>
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ include::partials/aurora/aurora-verify-peering-connections.adoc[]
|
|||
== Deploying {project_name}
|
||||
|
||||
Now that an Aurora database has been established and linked with all of your ROSA clusters, the next step is to deploy {project_name} as described in the <@links.ha id="deploy-keycloak-kubernetes" /> {section} with the JDBC url configured to use the Aurora database writer endpoint.
|
||||
To do this, create a `{project_name}` CR with the following adjustments:
|
||||
To do this, create a `Keycloak` CR with the following adjustments:
|
||||
|
||||
. Update `spec.db.url` to be `jdbc:aws-wrapper:postgresql://$HOST:5432/keycloak` where `$HOST` is the
|
||||
<<aurora-writer-url, Aurora writer endpoint URL>>.
|
||||
|
|
|
|||
|
|
@ -217,13 +217,13 @@ For both the Primary and Backup cluster, perform the following steps:
|
|||
+
|
||||
.. Log in to the ROSA cluster
|
||||
+
|
||||
.. Ensure the {project_name} CR has the following configuration
|
||||
.. Ensure the `Keycloak` CR has the following configuration
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
<#noparse>
|
||||
apiVersion: k8s.keycloak.org/v2alpha1
|
||||
kind: {project_name}
|
||||
kind: Keycloak
|
||||
metadata:
|
||||
name: keycloak
|
||||
spec:
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ The {infinispan-operator-docs}#setting-up-xsite[Setting Up Cross-Site] documenta
|
|||
+
|
||||
A basic example is provided in this {section} using the credentials, tokens, and TLS Keystore/Truststore created by the commands from the previous steps.
|
||||
+
|
||||
.The {jdgserver_name} CR for `{site-a}`
|
||||
.The `Infinispan` CR for `{site-a}`
|
||||
[source,yaml]
|
||||
----
|
||||
include::examples/generated/ispn-site-a.yaml[tag=infinispan-crossdc]
|
||||
|
|
@ -163,10 +163,10 @@ include::examples/generated/ispn-site-a.yaml[tag=infinispan-crossdc]
|
|||
<13> The {ocp} API URL for the remote site.
|
||||
<14> The secret with the access toke to authenticate into the remote site.
|
||||
+
|
||||
For `{site-b}`, the {jdgserver_name} CR looks similar to the above.
|
||||
For `{site-b}`, the `Infinispan` CR looks similar to the above.
|
||||
Note the differences in point 4, 11 and 13.
|
||||
+
|
||||
.The {jdgserver_name} CR for `{site-b}`
|
||||
.The `Infinispan` CR for `{site-b}`
|
||||
[source,yaml]
|
||||
----
|
||||
include::examples/generated/ispn-site-b.yaml[tag=infinispan-crossdc]
|
||||
|
|
@ -179,7 +179,7 @@ include::examples/generated/ispn-site-b.yaml[tag=infinispan-crossdc]
|
|||
The {jdgserver_name} {infinispan-operator-docs}#creating-caches[Cache CR] allows deploying the caches in the {jdgserver_name} cluster.
|
||||
Cross-site needs to be enabled per cache as documented by {infinispan-xsite-docs}[Cross Site Documentation].
|
||||
The documentation contains more details about the options used by this {section}.
|
||||
The following example shows the Cache CR for `{site-a}`.
|
||||
The following example shows the `Cache` CR for `{site-a}`.
|
||||
+
|
||||
.sessions in `{site-a}`
|
||||
[source,yaml]
|
||||
|
|
@ -191,7 +191,7 @@ Set this for the caches `sessions`, `authenticationSessions`, `offlineSessions`,
|
|||
<2> The remote site name.
|
||||
<3> The cross-site communication, in this case, `SYNC`.
|
||||
+
|
||||
For `{site-b}`, the Cache CR is similar except in point 2.
|
||||
For `{site-b}`, the `Cache` CR is similar except in point 2.
|
||||
+
|
||||
.session in `{site-b}`
|
||||
[source,yaml]
|
||||
|
|
@ -217,6 +217,6 @@ kubectl wait --for condition=CrossSiteViewFormed --timeout=300s infinispans.infi
|
|||
|
||||
== Next steps
|
||||
|
||||
After infinispan is deployed and running, use the procedure in the <@links.ha id="connect-keycloak-to-external-infinispan"/> {section} to connect your {project_name} cluster with the {jdgserver_name} cluster.
|
||||
After {jdgserver_name} is deployed and running, use the procedure in the <@links.ha id="connect-keycloak-to-external-infinispan"/> {section} to connect your {project_name} cluster with the {jdgserver_name} cluster.
|
||||
|
||||
</@tmpl.guide>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
title="Multi-site deployments"
|
||||
summary="Connect multiple {project_name} deployments in different sites to increase the overall availability" >
|
||||
|
||||
{project_name} supports deployments that consist of multiple {project_name} instances that connect to each other using its embedded Infinispan; load balancers can distribute the load evenly across those instances.
|
||||
{project_name} supports deployments that consist of multiple {project_name} instances that connect to each other using its Infinispan caches; load balancers can distribute the load evenly across those instances.
|
||||
Those setups are intended for a transparent network on a single site.
|
||||
|
||||
The {project_name} high-availability guide goes one step further to describe setups across multiple sites.
|
||||
|
|
|
|||
|
|
@ -20,6 +20,6 @@
|
|||
|
||||
// Other common attributes
|
||||
:ocp: OpenShift
|
||||
:ispn-operator: Infinispan Operator
|
||||
:ispn-operator: {jdgserver_name} Operator
|
||||
:site-a: Site-A
|
||||
:site-b: Site-B
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
[[infinispan-credentials]]
|
||||
. Configure the credential to access the Infinispan cluster.
|
||||
. Configure the credential to access the {jdgserver_name} cluster.
|
||||
+
|
||||
{project_name} needs this credential to be able to authenticate with the Infinispan cluster.
|
||||
{project_name} needs this credential to be able to authenticate with the {jdgserver_name} cluster.
|
||||
The following `identities.yaml` file sets the username and password with admin permissions
|
||||
+
|
||||
[source,yaml,subs="+attributes"]
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
. Install the https://infinispan.org/docs/infinispan-operator/main/operator.html#installation[Infinispan Operator]
|
||||
. Install the {infinispan-operator-docs}#installation[{jdgserver_name} Operator]
|
||||
|
|
|
|||
|
|
@ -1,2 +1,2 @@
|
|||
* OpenShift or Kubernetes cluster running
|
||||
* Understanding of the https://infinispan.org/docs/infinispan-operator/main/operator.html[Infinispan Operator]
|
||||
* Understanding of the {infinispan-operator-docs}[{jdgserver_name} Operator]
|
||||
|
|
|
|||
Loading…
Reference in a new issue