Docs: deploying Infinispan with Operator #569
Conversation
pruivo
commented
Oct 12, 2023
•
pruivo
commented
- Write single cluster deployment
- Write cross-site deployment
pruivo
force-pushed
the
t_ispn_operator
branch
from
9775b8b to
ff1abb1
Compare
pruivo
force-pushed
the
t_ispn_operator
branch
from
ff1abb1 to
3c88597
Compare
There was a problem hiding this comment.
Hi @pruivo - thank you for these two great step-by-step guides. I moved the includes to a separate folder, this way they are not converted to separated pages by Antora.
I did some re-rewording in some places to have shorter sentences and to use the active voice where it was previously the passive voice. Please review my changes to see if I slipped in some mistakes doing that.
Two questions remand open for me:
- I didn't see the Gossip Router mentioned in here, and that we deploy it only in one datacenter. Deploying only one is AFAIK still the recommendation, so I would expect this to be mentioned in the docs.
- I found that the work cache is in Keycloak a replicated cache, while it seems to be a distributed cache in the external Infinispan. Could you please comment on this / discuss with this the team? We can also handle this in a separate issue if it requires additional investigation / alignment.
ahus1
force-pushed
the
t_ispn_operator
branch
from
3b7283e to
eca0095
Compare
|
@pruivo - one more thing: Please document on how to update the memory settings (requested + limit on Kuberentes level, JVM parameters for heap). A first iteration would IMHO be: Use the calculation we have to calculate the memory for the 3-node Keycloak deployment, and then use the same setting for Infinispan, assuming that the RAM usage for sessions would be similar. |
pruivo
force-pushed
the
t_ispn_operator
branch
from
eca0095 to
667c918
Compare
|
|
||
| == Audience | ||
|
|
||
| This guide describes the procedures required to deploy {ispn} in a multiple cluster environment (cross-site). |
There was a problem hiding this comment.
s/multiple cluster/multi-cluster?
| This guide describes the procedures required to deploy {ispn} in a multiple cluster environment (cross-site). | ||
| For simplicity, this guide uses the minimum configuration possible that allows {kc} to be used with an external {ispn}. | ||
|
|
||
| This guide assumes two {ocp} clusters named `{site-a}` and `{site-b}` |
| include::partial$running/infinispan-install-operator.adoc[] | ||
| include::partial$running/infinispan-credentials.adoc[] | ||
| + | ||
| Those commands are required both {ocp} clusters. |
There was a problem hiding this comment.
A couple of suggestions:
"These commands are required by both {ocp} clusters."
OR
"These commands must be executed on both {ocp} clusters."
| + | ||
| Those commands are required both {ocp} clusters. | ||
| Although we use the same credentials in both {ispn} clusters, they could have been different. | ||
| Just adapt your {kc} configuration. |
There was a problem hiding this comment.
Although true, I feel like this is deviating from the minimal required steps and the docs would be more focused if omitted.
|
|
||
| . Create a service account. | ||
| + | ||
| A service account is required to establish the cross-site connection. |
There was a problem hiding this comment.
"...connection between clusters."
| The {ispn} {operator-docs}#creating-caches[Cache CR] allows to deploy the caches in the {ispn} cluster. | ||
| Cross-site needs to be enabled per cache as documented by {xsite-docs}[Cross Site Documentation]. | ||
| The documentation contains more details about the options used by this guide. | ||
| In the following example shows the Cache CR for `{site-a}`. |
| + | ||
| The https://infinispan.org/docs/infinispan-operator/main/operator.html#creating-clusters[Creating Infinispan clusters] documentation provides all the information on how to create and configure your Infinispan cluster. | ||
| + | ||
| For simplicity, we provide the following example as a starting point. |
There was a problem hiding this comment.
This sentence doesn't really add anything, I think we can remove it.
| @@ -15,12 +15,12 @@ See xref:running/index.adoc[] for additional guides. | |||
|
|
|||
| * OpenShift or Kubernetes cluster running. | |||
| * Existing xref:running/keycloak-deployment.adoc[Basic Keycloak deployment] as it will be extended. | |||
| * Existing deployment of Infinispan with the Operator (TODO). | |||
| * Existing Infinispan deployment, for example, one of xref:running/infinispan-deployment.adoc[] or xref:running/keycloak-with-external-infinispan.adoc[]. | |||
There was a problem hiding this comment.
Should "infinispan" be "{ispn}"?
There was a problem hiding this comment.
ispn attribute does not exist in this file.
| @@ -0,0 +1,37 @@ | |||
| . Configure the credential to access the Infinispan cluster. | |||
| + | |||
| Keycloak needs this credential to be able to access the cluster. | |||
There was a problem hiding this comment.
"Keycloak needs this credential to be able to authenticate with the {ispn} cluster."?
| . Configure the credential to access the Infinispan cluster. | ||
| + | ||
| Keycloak needs this credential to be able to access the cluster. | ||
| By default, the Infinispan Operator generates credentials with a random password and stores it in a secret. |
There was a problem hiding this comment.
I think we should just document how to define a pre-configured password and then provide a link to the Infinispan Operator docs as further reading at the end of this section. I don't think a Keycloak user cares about Infinispan's defaults etc, just what they need to do to get started and using pre-configured credentials is the easiest way.
|
@ahus1 thanks for that! Looks good, just squashed the commits. I didn't mention the Gossip Router because I'm trying to keep the CRs as minimal as possible and, it is most likely related to how the Openshift is configured. It has been the default to have 1 Gossip Router per site and I haven't heard any reports from customers. In the worst case, we can write some knowledge article or some tunning guide at the end. The Infinispan memory configuration is documented in our guides, which are linked. If you have some idea of how much memory is required per session, we can try to give some guidance. The |
pruivo
force-pushed
the
t_ispn_operator
branch
from
667c918 to
be0f312
Compare
There was a problem hiding this comment.
Thanks you for the updates. I was concerned with the Gossip Router as I think we did the failure testing with only one Gossip Router and not two. Would it make sense to repeat the failure testing with two Gossip Routers? If yes, please create a follow-up issue.
