[ https://issues.jboss.org/browse/ISPN-6673?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-6673 at 7/21/16 6:16 AM: -------------------------------------------------------------------- WARNING - WORK IN PROGRESS NOTES The procedure for OpenShift looks like the following: # Start OpenShift cluster using: {code} oc cluster up {code} Note you are logged as a developer. # Create new Infinispan cluster using standard configuration: {code} oc new-app slaskawi/infinispan-experiments {code} # Node that you should always be using labels for your clusters. I'll call my cluster=cluster-1 {code} oc env dc/infinispan-experiments OPENSHIFT_KUBE_PING_LABELS=cluster=cluster-1 oc env dc/infinispan-experiments OPENSHIFT_KUBE_PING_NAMESPACE=myproject oc label dc/infinispan-experiments cluster=cluster-1 {code} # Scale up the deployment {code} oc scale dc/infinispan-experiments --replicas=3 {code} # Create a route to the service {code} oc expose svc/infinispan-experiments {code} # Add some entries using REST {code} curl -X POST -H 'Content-type: text/plain' -d 'test' http://infinispan-experiments-myproject.192.168.0.17.xip.io/rest/default/1 {code} # Check if the entry is there {code} curl -X GET -H 'Content-type: text/plain' http://infinispan-experiments-myproject.192.168.0.17.xip.io/rest/default/1 {code} # Now we can spin up a new cluster. Again, it's very important to use labels which will avoid joining those two clusters together. The new Docker image with Infinispan Hot Rod server needs to contain the following Remote Cache Store definition: {code} diff --git a/server/infinispan-server-9.0.0-SNAPSHOT/standalone/configuration/cloud.xml b/server/infinispan-server-9.0.0-SNAPSHOT/standalone/configuration/cloud.xml index 6cb865d..8623850 100644 --- a/server/infinispan-server-9.0.0-SNAPSHOT/standalone/configuration/cloud.xml +++ b/server/infinispan-server-9.0.0-SNAPSHOT/standalone/configuration/cloud.xml @@ -158,6 +158,12 @@ </subsystem> <subsystem xmlns="urn:infinispan:server:core:9.0" default-cache-container="clustered"> <cache-container name="clustered" default-cache="default" statistics="true"> + <persistence passivation="false"> + <remote-store xmlns="urn:infinispan:config:store:remote:9.0" + cache="default" hotrod-wrapping="true" ping-on-start="true" read-only="true"> + <remote-server host="infinispan-experiments-myproject.192.168.0.17.xip.io" port="11222" /> + </remote-store> + </persistence> <transport lock-timeout="60000"/> <global-state/> <distributed-cache-configuration name="transactional" mode="SYNC" start="EAGER"> {code} was (Author: sebastian.laskawiec): THESE ARE WORK IN PROGRESS NOTES The procedure for OpenShift looks like the following: # Start OpenShift cluster using: {code} oc cluster up {code} Note you are logged as a developer. # Create new Infinispan cluster using standard configuration: {code} oc new-app slaskawi/infinispan-experiments {code} # Node that you should always be using labels for your clusters. I'll call my cluster=cluster-1 {code} oc env dc/infinispan-experiments OPENSHIFT_KUBE_PING_LABELS=cluster=cluster-1 oc label dc/infinispan-experiments cluster=cluster-1 {code} # Scale up the deployment {code} oc scale dc/infinispan-experiments --replicas=3 {code} # Create a route to the service {code} oc expose svc/infinispan-experiments {code} # Add some entries using REST {code} curl -X POST -H 'Content-type: text/xml' -d 'test' http://infinispan-experiments-myproject.192.168.0.17.xip.io/rest/default/1 {code} # Now we can spin up a new cluster. Again, it's very important to use labels which will avoid joining those two clusters together. In my case (just a POC) I will simply export the build configuration and import it back again. However in Production environment you will probably have some changes in your Docker image. {code} oc export -o yaml dc/infinispan-experiments > dc_2.yaml .. edit the name and labels .. oc create -f dc_2.yaml {code} # Now let's verify if everything looks good: {code} oc status -v In project My Project (myproject) on server https://192.168.0.17:8443 http://infinispan-experiments-myproject.192.168.0.17.xip.io to pod port 8080-tcp (svc/infinispan-experiments) dc/infinispan-experiments deploys istag/infinispan-experiments:latest deployment #3 deployed 7 minutes ago - 1 pod deployment #2 deployed 8 minutes ago deployment #1 deployed 38 minutes ago dc/infinispan-experiments-2 deploys istag/infinispan-experiments:latest deployment #1 running for 12 seconds - 1 pod {code} # Now we need to expose a service {code} oc expose dc/infinispan-experiments-2 {code} # At this point we have 2 clusters (the old one with selector {{cluster=cluster-1}} and the new one with selector {{cluster=cluster-2}}). Depending on our client we might want (or not) to expose a route to {{svc/infinispan-experiments-2}} or we are good with just a service. # Since the [Infinispan Upgrade Procedure|http://infinispan.org/docs/stable/user_guide/user_guide.html#_R...] requires port {{4444}} we need to edit the service in source cluster and add it: {code} $ oc edit svc/infinispan-experiments .. add port 4444 .. {code} # Get the IP address for source cluster service ({{svc/infinispan-experiments}}) {code} oc describe svc/infinispan-experiments .. write down: IP: 172.30.66.108 .. {code} The connection string for the cluster will be {{jmx://172.30.66.108:4444/clustered/default}} # -- This message was sent by Atlassian JIRA (v6.4.11#64026)