Re: Help needed to check demo-trunk solr functionality following switch to docker

[Jacques Le Roux]

Thanks for the clarification Daniel, much appreciated

Le 29/03/2023 à 11:52, Daniel Watford a écrit :

Hi Jacques,

On the page, https://github.com/apache/ofbiz-framework, at the right-hand
side, under Releases and above Contributors, you will see the Packages
section. This lists the packages associated with the ofbiz-framework github
repository.

Clicking on the OFBiz package above will take you to
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz.


Container systems, such as Docker and Podman, pull container images from
registries.

Examples of some well known registries are:
- registry-1.docker.io  (Docker Hub)
- ghcr.io (GitHub Container Registry)
- mcr.microsoft.com (Microsoft Container Registry)

Organisations can also operate their own private container registries.

Within a container registry, we find repositories. Some examples:
- ghcr.io/apache/ofbiz (OFBiz container repository)
- mcr.microsoft.com/azure-cli (Azure command line interface)
- hub.docker.com/_/httpd/ (Apache HTTPd)

Repositories store multiple versions of container images, some of which are
tagged. We can see all container images in the ofbiz repository at these
links:
-
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=tagged
-
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=untagged

The tags help users find a particular version of a container image. Tags
can be 'moved' to different container image versions as newer versions are
published. A common tag, although not used in the images published for
OFBiz, is the 'latest' tag.

Note: Although the above discusses 'container images', really we are just
talking about files arranged in a well known manner and/or accessible
behind the well known REST APIs of the registries. Container registries are
often implemented using artifact management systems, such as Artifactory
and Nexus. We can think of a container registry as analogous to a Maven
repository in that artifacts are laid out in a common format.

GitHub Packages is a product offering from GitHub to provide storage and
publication of various artifacts (packages). The GitHub Container Registry
is a component of that product offering.

When choosing a place to publish OFBiz container images to, I considered
Docker Hub, the Apache Foundation's Artifactory instance and GitHub
Packages.

There was sufficient friction to getting up and running publishing to
Docker Hub. I would have needed assistance from INFRA, and documentation
wasn't clear on precisely what information/support I would have needed to
request.

Plus, the recent policy changes from Docker Inc meant I didn't want to
expend too much effort there.

GitHub packages seemed a nice low-friction direction to go in as it
integrated well with GitHub Actions. It also appeared to be growing in
recognition as a location to publish container image.

During the GitHub Actions build of the OFBiz container images (see
.github/workflows/docker-image.yml), we use the docker/login-action to log
in to ghcr.io (GitHub Packages Container Registry). The login makes use of
the GITHUB_TOKEN secret which is included by default in the workflow. No
additional configuration or permissions were required to access the
registry.

Later in the workflow, we use the docker/build-push-action to create the
docker image and push to ghcr.io.

We do not publish the OFBiz container images to DockerHub. However we do
build our container images based on the eclipse-temurin:17 image.

Since the image 'eclipse-temurin:17' identifier does not include a
hostname, the default hostname of registry-1.docker.io (i.e. Docker Hub) is
used. We do therefore depend on an image from Docker Hub, although we could
explore whether eclipse-temurin is available from any other public
container registries and use that instead.

Hope that helps,

Dan.

On Wed, 29 Mar 2023 at 10:01, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:

Daniel,

I have another minor question: how works and special is
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz ? I can't
see it locally nor
from https://github.com/apache/ofbiz-framework
I guess it's not related to Docker Hub, right ?

TIA

Le 29/03/2023 à 09:33, Daniel Watford a écrit :

Hi Jacques,

Answers to your questions below.

1 - Yes, we should wait to be sure that nothing has been broken by the

move to a container deployment to trunk. If/when we are happy then we can

merge ofbiz-tools PR5 into master, bringing in and squashing the commits

currently in the docker-experimental branch.

If we discover an issue with docker-trunk we can revert. I decided to

use a PR to capture the changes to make it a bit easier for folks without

access to ofbiz-vm1 to review.

I have seen some errors in the logs related to lack of database

connections, probably due to my use of a Postgres database for the
demo-trunk

deployment. As I write this I realise that by using a postgres rather

than the embedded Derby I have already failed in delivering a like-for-like

version of demo-trunk. If wanted by the dev community, I can switch

demo-trunk to use Derby, but I think it is valuable to have an external
database

deployment publicly visible.

I will look into the errors in the logs soon.


2 - I don't have a problem with using AsciiDoc instead of Markdown, I

just haven't dealt with it myself yet.

Perhaps someone else could convert that file for us. :)

I agree that the content in DOCKER.md is not intended to form part of

the official OFBiz documentation, but I imagine in the future we might want
to

point potential users towards the container images as an unsupported

convenience. In that case we would probably need to rework DOCKER.[md|adoc]
to

give appropriate deployment guidance, perhaps with separate documents to

explain the container build process.

3 - Creating the ofbiz-12723 branch in apache/ofbiz-framework rather

than danwatford/ofbiz-framework was an oversight on my part. I'll get it

cleaned up.

Thanks,

Dan.

On Wed, 29 Mar 2023 at 08:09, Jacques Le Roux <

jacques.le.r...@les7arts.com> wrote:

     Hi Daniel,

     First, thanks for all your work!

     I had a quick look and Solr demo is working as expected. We are not

up to date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645.

     Now, I have few questions/notes for you and the community. You

mentioned in a previous email:

     Le 22/03/2023 à 17:49, Daniel Watford a écrit :

     If consensus is established, then changes shall be initially made

in a way

     allowing them to be quickly reversed if needed. Once the demo-trunk

site is

     observed as running correctly, and with refreshes applied daily,

then more

     permanent changes can be applied to the demo VM and changes

committed to

     https://github.com/apache/ofbiz-tools/tree/master/demo-backup

accordingly.

      1. I guess we should now wait for at least another day before

merging the docker-experimental branch into ofbiz-tools, right?

      2. We switched from using Markdown to AsciiDoc. I just want to say

that you created

         https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md.

I don't think it's an issue because we don't want to expose that in the

         site, it's rather for Docker users, right?
      3. (unrelated to docker effort) I guess we should remove the

https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch, right?
(there

         are more docker unrelated branches to clean, I'll send another

email for that)

     Again, thanks!

     Jacques

     Le 28/03/2023 à 18:09, Daniel Watford a écrit :

     Hello,

     Perhttps://issues.apache.org/jira/browse/OFBIZ-12786, the

demo-trunk site

     is now hosted by a docker container running on

VMofbiz-vm1.apache.org  <http://ofbiz-vm1.apache.org>.

     The changes to the host are captured in PR,
     https://github.com/apache/ofbiz-tools/pull/5.

     The previous approach to demo-trunk deployment patched the solr

plugin to

     set the solr URL tohttps://demo-trunk.ofbiz.apache.org/solr. You

can view

     the patch here -

https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch

     .

     I believe I have configured the new demo-trunk container to produce

the

     same solr url, but by using configuration rather than source code

changes.

     I don't know much about the use of Solr in OFBiz so don't know how

to check

     that the original demo-trunk behaviour has been maintained.

     Please could someone familiar with Solr in OFBiz take a look
     https://demo-trunk.ofbiz.apache.org/partymgr/control/main  and see

if Solr

     is operating as expected.

     Thanks,

     Dan.

--
Daniel Watford