[JBoss JIRA] (ISPN-6054) Docker image cannot build website
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-6054?page=com.atlassian.jira.plugin... ]
Donald Naro commented on ISPN-6054:
-----------------------------------
[~gustavonalle] Hey Gustavo, do you think you could have a look at this please? It's an old one but I've had issues with the docker image for the community site as well. I thought I'd assign to you as you are the Docker Lord.
> Docker image cannot build website
> ---------------------------------
>
> Key: ISPN-6054
> URL: https://issues.redhat.com/browse/ISPN-6054
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation
> Reporter: Emmanuel Bernard
> Assignee: Gustavo Fernandes
> Priority: Major
>
> There are several issues with the Docker image:
> 1. it uses Ruby 2.2 which apparently make Awestruct 0.5.7.RC2 + Guard fail
> 2. the Gemfile.lock conflicts
> For 1. the error is as followed https://gist.github.com/emmanuelbernard/0524a56f2f859569c634
> The best is for Awestruct to fix the issue (assuming the analysis is correct). The alternative is to install rvm inside the docker image to controll the ruby version used. It requires a few experimentations (probably 2 to 4 hours of work)
> For 2. the problem is as followed:
> - docker build installs and create a Gemfile.lock with specific versions
> - the host might already have a Gemfile.lock or worse, does not have one
> - when running docker, we do bind the host directory on top of the docker directory
> - so the host Gemfile.lock is used (different from Docker's gemfile.lock) and this will look for potentially incorrect dependencies and fail
> The solutions to 2 are:
> - create a build_docker.sh which will build the docker image, remove Gemfile.lock from the host and rerun the rake setup step to rebuild the Gemfile.lock to the right value ; since the host dir will be mapped, the Gemfile.lock will survive a docker image restart
> - change the scripts to store the Gemfile.lock somewhere in a non mapped directory of the docker image and use an environment variable set in Dockerfile to influence our Rakefile (we do that already with the env variable BIND)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-6054) Docker image cannot build website
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-6054?page=com.atlassian.jira.plugin... ]
Donald Naro reassigned ISPN-6054:
---------------------------------
Assignee: Donald Naro
> Docker image cannot build website
> ---------------------------------
>
> Key: ISPN-6054
> URL: https://issues.redhat.com/browse/ISPN-6054
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation
> Reporter: Emmanuel Bernard
> Assignee: Donald Naro
> Priority: Major
>
> There are several issues with the Docker image:
> 1. it uses Ruby 2.2 which apparently make Awestruct 0.5.7.RC2 + Guard fail
> 2. the Gemfile.lock conflicts
> For 1. the error is as followed https://gist.github.com/emmanuelbernard/0524a56f2f859569c634
> The best is for Awestruct to fix the issue (assuming the analysis is correct). The alternative is to install rvm inside the docker image to controll the ruby version used. It requires a few experimentations (probably 2 to 4 hours of work)
> For 2. the problem is as followed:
> - docker build installs and create a Gemfile.lock with specific versions
> - the host might already have a Gemfile.lock or worse, does not have one
> - when running docker, we do bind the host directory on top of the docker directory
> - so the host Gemfile.lock is used (different from Docker's gemfile.lock) and this will look for potentially incorrect dependencies and fail
> The solutions to 2 are:
> - create a build_docker.sh which will build the docker image, remove Gemfile.lock from the host and rerun the rake setup step to rebuild the Gemfile.lock to the right value ; since the host dir will be mapped, the Gemfile.lock will survive a docker image restart
> - change the scripts to store the Gemfile.lock somewhere in a non mapped directory of the docker image and use an environment variable set in Dockerfile to influence our Rakefile (we do that already with the env variable BIND)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-6054) Docker image cannot build website
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-6054?page=com.atlassian.jira.plugin... ]
Donald Naro reassigned ISPN-6054:
---------------------------------
Assignee: Gustavo Fernandes (was: Donald Naro)
> Docker image cannot build website
> ---------------------------------
>
> Key: ISPN-6054
> URL: https://issues.redhat.com/browse/ISPN-6054
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation
> Reporter: Emmanuel Bernard
> Assignee: Gustavo Fernandes
> Priority: Major
>
> There are several issues with the Docker image:
> 1. it uses Ruby 2.2 which apparently make Awestruct 0.5.7.RC2 + Guard fail
> 2. the Gemfile.lock conflicts
> For 1. the error is as followed https://gist.github.com/emmanuelbernard/0524a56f2f859569c634
> The best is for Awestruct to fix the issue (assuming the analysis is correct). The alternative is to install rvm inside the docker image to controll the ruby version used. It requires a few experimentations (probably 2 to 4 hours of work)
> For 2. the problem is as followed:
> - docker build installs and create a Gemfile.lock with specific versions
> - the host might already have a Gemfile.lock or worse, does not have one
> - when running docker, we do bind the host directory on top of the docker directory
> - so the host Gemfile.lock is used (different from Docker's gemfile.lock) and this will look for potentially incorrect dependencies and fail
> The solutions to 2 are:
> - create a build_docker.sh which will build the docker image, remove Gemfile.lock from the host and rerun the rake setup step to rebuild the Gemfile.lock to the right value ; since the host dir will be mapped, the Gemfile.lock will survive a docker image restart
> - change the scripts to store the Gemfile.lock somewhere in a non mapped directory of the docker image and use an environment variable set in Dockerfile to influence our Rakefile (we do that already with the env variable BIND)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-6607) extra closing tag symbol
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-6607?page=com.atlassian.jira.plugin... ]
Donald Naro closed ISPN-6607.
-----------------------------
Resolution: Won't Do
> extra closing tag symbol
> -------------------------
>
> Key: ISPN-6607
> URL: https://issues.redhat.com/browse/ISPN-6607
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation
> Reporter: Martin Vrabel
> Assignee: Donald Naro
> Priority: Trivial
>
> in section 8.2.2 [#http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_sample_xml_configuration_2]
> the closing tag after .jpa.entity.Vehicle"{color:#d04437}>{color} should not be there
> {code}
> <local-cache name="vehicleCache">
> <persistence passivation="false">
> <jpa-store xmlns="urn:infinispan:config:store:jpa:7.0"
> persistence-unit="org.infinispan.persistence.jpa.configurationTest"
> entity-class="org.infinispan.persistence.jpa.entity.Vehicle">
> />
> </persistence>
> </local-cache>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-9994) Explanations for XSiteRepl "Taking a site back online" is out of date and confusion
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-9994?page=com.atlassian.jira.plugin... ]
Donald Naro closed ISPN-9994.
-----------------------------
Resolution: Out of Date
> Explanations for XSiteRepl "Taking a site back online" is out of date and confusion
> -----------------------------------------------------------------------------------
>
> Key: ISPN-9994
> URL: https://issues.redhat.com/browse/ISPN-9994
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Affects Versions: 9.4.8.Final
> Environment: http://infinispan.org/docs/stable/user_guide/user_guide.html#taking_a_sit...
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Major
>
> The chapter 26.3.2 statement is that bringSiteOnline() need to be invoked for all nodes. This is not (longer) correct, it need to be invoked for all caches.
> The new GlobalXSiteAdminOperations component will do this at once.
> Another thing is that the bringStiteOnline() will only enable the repl, but not do a full update so only new put's will go to the other site.
> pushState(site) will bring the site online and transfer the state.
> Also the wording could be confusion, sometimes it is mentioned to invoke the method on master and sometimes on backup.
> It should be clear that the invocation is needed on the current active site - the site which contain the up-to-date caches - otherwise the result is that the correct site is overriden with the outdated caches!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years