gerrit docker images, different first-run

[James Muir]

The docker images available on docker hub are very useful for local testing.  Thank-you for producing them.

https://hub.docker.com/r/gerritcodereview/gerrit

I have been using the image gerrit:3.7.2-ubuntu20.  In its dockerfile, you can see that this image has five volumes, including "/var/gerrit/etc".

It is convenient to bind mount "/var/gerrit/etc" from the container to a host path so I can edit config on the host and restart gerrit.

Unfortunately, when I do that, I notice that gerrit goes through a different "first-run".  The gerrit server does not display the welcome screen (which leads you to plugin selection), and the "admin" user is not automatically created.

Is this intentional?

It must be that when gerrit starts up, it sees that the path /var/gerrit/etc exists (even though there are no files inside it) and decides to produce a different initial gerrit.conf file.

Here is the compose file I am using if anyone is interested (I run it using podman).  Note that there are good example compose files given on the docker hub page.

version: '3'

services:

 gerrit:

   image: docker.io/gerritcodereview/gerrit:3.7.2-ubuntu20

   container_name: gerrit-server-container

   ports:

     - "8080:8080"

     - "29418:29418"

   volumes:

     - "./var-gerrit-etc:/var/gerrit/etc"

# NB: make host directory var-gerrit-etc writable by all users to avoid errors.

#     the user "gerrit" is not known to the host.

   environment:

     - CANONICAL_WEB_URL=http://gerrit.example.test:8080

   tty: true

-James M

[Luca Milanesio]

On 29 Apr 2023, at 17:32, James Muir <jm...@crypto4a.com> wrote:

The docker images available on docker hub are very useful for local testing.  Thank-you for producing them.

https://hub.docker.com/r/gerritcodereview/gerrit

I have been using the image gerrit:3.7.2-ubuntu20.  In its dockerfile, you can see that this image has five volumes, including "/var/gerrit/etc".

It is convenient to bind mount "/var/gerrit/etc" from the container to a host path so I can edit config on the host and restart gerrit.

Unfortunately, when I do that, I notice that gerrit goes through a different "first-run".  The gerrit server does not display the welcome screen (which leads you to plugin selection), and the "admin" user is not automatically created.

Is this intentional?

Yes, because if you already have a configuration then it assumes you don’t need to initialise a new site from scratch.

Luca.

It must be that when gerrit starts up, it sees that the path /var/gerrit/etc exists (even though there are no files inside it) and decides to produce a different initial gerrit.conf file.

Here is the compose file I am using if anyone is interested (I run it using podman).  Note that there are good example compose files given on the docker hub page.

version: '3'

services:

 gerrit:

   image: docker.io/gerritcodereview/gerrit:3.7.2-ubuntu20

   container_name: gerrit-server-container

   ports:

     - "8080:8080"

     - "29418:29418"

   volumes:

     - "./var-gerrit-etc:/var/gerrit/etc"

# NB: make host directory var-gerrit-etc writable by all users to avoid errors.

#     the user "gerrit" is not known to the host.

   environment:

     - CANONICAL_WEB_URL=http://gerrit.example.test:8080

   tty: true

-James M

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CAM-GoEU%3DVPN8aKQHcJWa_uXQL7o%3DBh0wBmyfOtHeGQuk90dcRA%40mail.gmail.com.

[James Muir]

On Sat, Apr 29, 2023 at 5:25 PM Luca Milanesio <luca.mi...@gmail.com> wrote:

It is convenient to bind mount "/var/gerrit/etc" from the container to a host path so I can edit config on the host and restart gerrit.

Unfortunately, when I do that, I notice that gerrit goes through a different "first-run".  The gerrit server does not display the welcome screen (which leads you to plugin selection), and the "admin" user is not automatically created.

Is this intentional?

Yes, because if you already have a configuration then it assumes you don’t need to initialise a new site from scratch.

But there is no existing configuration data.  On the host, the directory ./var-gerrit-etc is empty.  When the container starts, gerrit sees an existing but empty /var/gerrit/etc and that changes its behaviour.

Is there a way to make it so that the first-run behaviour is the same in the two cases?  (i.e. one case being where you create and run a container without any bind mounts, and the other case being where you create and run a container with /var/gerrit/etc bind mounted.)

[Björn Pedersen]

James Muir schrieb am Samstag, 29. April 2023 um 23:51:20 UTC+2:

On Sat, Apr 29, 2023 at 5:25 PM Luca Milanesio <luca.mi...@gmail.com> wrote:

It is convenient to bind mount "/var/gerrit/etc" from the container to a host path so I can edit config on the host and restart gerrit.

Unfortunately, when I do that, I notice that gerrit goes through a different "first-run".  The gerrit server does not display the welcome screen (which leads you to plugin selection), and the "admin" user is not automatically created.

Is this intentional?

Yes, because if you already have a configuration then it assumes you don’t need to initialise a new site from scratch.

But there is no existing configuration data.  On the host, the directory ./var-gerrit-etc is empty.  When the container starts, gerrit sees an existing but empty /var/gerrit/etc and that changes its behaviour.

You probably had something in /var/gerrit/git/All-Projects.git  (check Check https://github.com/GerritCodeReview/docker-gerrit/blob/master/ubuntu/22/entrypoint.sh to see when init is invoked in the container),

[James Muir]

On Tue, May 2, 2023 at 4:15 AM 'Björn Pedersen' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

James Muir schrieb am Samstag, 29. April 2023 um 23:51:20 UTC+2:

On Sat, Apr 29, 2023 at 5:25 PM Luca Milanesio <luca.mi...@gmail.com> wrote:

It is convenient to bind mount "/var/gerrit/etc" from the container to a host path so I can edit config on the host and restart gerrit.

Unfortunately, when I do that, I notice that gerrit goes through a different "first-run".  The gerrit server does not display the welcome screen (which leads you to plugin selection), and the "admin" user is not automatically created.

Is this intentional?

Yes, because if you already have a configuration then it assumes you don’t need to initialise a new site from scratch.

But there is no existing configuration data.  On the host, the directory ./var-gerrit-etc is empty.  When the container starts, gerrit sees an existing but empty /var/gerrit/etc and that changes its behaviour.

You probably had something in /var/gerrit/git/All-Projects.git  (check Check https://github.com/GerritCodeReview/docker-gerrit/blob/master/ubuntu/22/entrypoint.sh to see when init is invoked in the container),

Thanks for the pointer to "entrypoint.sh".  I had been looking for a reference back to the repo used to build the docker image (I did not find one on gerrit hub).

No, there was nothing inside /var/gerrit/git/All-Projects.git.

The only difference between the two cases is the existence of an empty /var/gerrit/etc.

It must be the command "java $JAVA_OPTS -jar /var/gerrit/bin/gerrit.war init" that behaves differently.

Is there a way to make it so that the first-run behaviour is the same in the two cases?

I may not be doing a very good job of explaining the two cases.  It is probably easiest to understand by trying the compose file (uncomment the "volumes" section to go from case 1 to case 2):

version: '3'

services:

 gerrit:

   image: docker.io/gerritcodereview/gerrit:3.7.2-ubuntu20

   container_name: gerrit-server-container

   ports:

     - "8080:8080"

     - "29418:29418"

   ## uncomment the "volumes" section to bind mount /var/gerrit/etc to the host

   ##   rm -rf var-gerrit-etc

   ##   mkdir var-gerrit-etc && chmod a+w var-gerrit-etc

   #volumes:

   #  - "./var-gerrit-etc:/var/gerrit/etc"

[James Muir]

Thanks for the pointer to "entrypoint.sh".  I had been looking for a reference back to the repo used to build the docker image (I did not find one on gerrit hub).

typo:  I meant "docker hub" not "gerrit hub". 

[Björn Pedersen]

James Muir schrieb am Dienstag, 2. Mai 2023 um 16:32:51 UTC+2:

Thanks for the pointer to "entrypoint.sh".  I had been looking for a reference back to the repo used to build the docker image (I did not find one on gerrit hub).

typo:  I meant "docker hub" not "gerrit hub". 

/var/gerrit/git is marked as  volume in the image,  so if you  restart it will be reusued (you should bin-mount it to a local directory for persistence anyway.) So probably it was not empty as you assumed. 

 

[Björn Pedersen]

Best practice would be to mount all dirs from 

```VOLUME ["/var/gerrit/git", "/var/gerrit/index", "/var/gerrit/cache", "/var/gerrit/db", "/var/gerrit/etc"]```

to local directories or named volumes.

 

[James Muir]

On Wed, May 3, 2023 at 3:53 AM 'Björn Pedersen' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Björn Pedersen schrieb am Mittwoch, 3. Mai 2023 um 09:50:05 UTC+2:

James Muir schrieb am Dienstag, 2. Mai 2023 um 16:32:51 UTC+2:

Thanks for the pointer to "entrypoint.sh".  I had been looking for a reference back to the repo used to build the docker image (I did not find one on gerrit hub).

typo:  I meant "docker hub" not "gerrit hub". 

/var/gerrit/git is marked as  volume in the image,  so if you  restart it will be reusued (you should bin-mount it to a local directory for persistence anyway.) So probably it was not empty as you assumed. 

I am not restarting the container.  I am creating a new one.  There is no data being reused.

The only difference is that I have an empty /var/gerrit/etc bind mounted in one case, and no bind mounts at all in the other.

I am able to reproduce this using both podman-compose and docker-compose.

This seems like a bug.

Thanks for trying to help.  It would be useful if someone could try to reproduce this using the compose file I posted.  If the behaviour is confirmed, then I will open a bug.

[Luca Milanesio]

Yes, please raise a bug :-)

Luca.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CAM-GoEXKGWzhj%3Drk3j4iTK0%3DULKfnnzaTGP9m7qjV-N0XdJ0Ww%40mail.gmail.com.

[James Muir]

On Wed, May 3, 2023 at 9:43 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

Yes, please raise a bug :-)

I am happy to do that, but I hoped someone else could confirm the behaviour first.

[luca.mi...@gmail.com]

Sent from my iPhone

On 3 May 2023, at 14:54, James Muir <jm...@crypto4a.com> wrote:



On Wed, May 3, 2023 at 9:43 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

Yes, please raise a bug :-)

I am happy to do that, but I hoped someone else could confirm the behaviour first.

I am not aware of any different behaviour when the volume is mounted externally, assuming you have the correct permissions in the file system of course.

Luca

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CAM-GoEXafDrhrUD%3D00BjL1SaN6GFaxKyPw2tdDODwvhCQrb5JQ%40mail.gmail.com.

[James Muir]

On Wed, May 3, 2023 at 2:33 PM <luca.mi...@gmail.com> wrote:

I am happy to do that, but I hoped someone else could confirm the behaviour first.

I am not aware of any different behaviour when the volume is mounted externally, assuming you have the correct permissions in the file system of course.

By "confirm the behaviour", I meant that I hoped someone else could try out the compose file and confirm that they also see the buggy behaviour.

[lucamilanesio]

I've run this locally with a local /tmp/etc directory containing the same gerrit.config as in the Docker image [1] and mounted as /var/gerrit/etc, it works as expected for me.

P.S. If you start with an empty etc, you will get the default generated gerrit.config, which is different from the one backed in the Docker image at [1].

If this is different from your expectations, then feel free to raise an issue with the exact steps to reproduce it.

HTH

Luca.

[1] https://gerrit.googlesource.com/gerrit-installer/+/refs/heads/master/fpm/etc/gerrit.config

[James Muir]

On Wed, May 3, 2023 at 6:24 PM lucamilanesio <luca.mi...@gmail.com> wrote:

On Wednesday, May 3, 2023 at 7:55:38 PM UTC+1 James Muir wrote:

On Wed, May 3, 2023 at 2:33 PM <luca.mi...@gmail.com> wrote:

I am happy to do that, but I hoped someone else could confirm the behaviour first.

I am not aware of any different behaviour when the volume is mounted externally, assuming you have the correct permissions in the file system of course.

By "confirm the behaviour", I meant that I hoped someone else could try out the compose file and confirm that they also see the buggy behaviour.

I've run this locally with a local /tmp/etc directory containing the same gerrit.config as in the Docker image [1] and mounted as /var/gerrit/etc, it works as expected for me.

P.S. If you start with an empty etc, you will get the default generated gerrit.config, which is different from the one backed in the Docker image at [1].

Thanks very much for giving the compose file a try and for your explanation.

I would guess that this works the way you expect because you had a hand in the creation of the deb package :-)

I did not know the deb package includes a special static gerrit.config file:

$ apt-get download gerrit

$ mkdir deb && cd deb

$ dpkg -x ../gerrit_3.8.0-0rc4_all.deb .

$ find .

.

./var

./var/gerrit

./var/gerrit/cache

./var/gerrit/bin

./var/gerrit/bin/gerrit.war

./var/gerrit/etc

./var/gerrit/etc/gerrit.config

./var/gerrit/lib

./var/gerrit/lib/out-of-the-box.jar

./var/gerrit/git

./var/gerrit/db

./var/gerrit/index

./var/gerrit/plugins

./var/gerrit/plugins/uploadvalidator.jar

./var/gerrit/plugins/avatars-gravatar.jar

./usr

./usr/share

./usr/share/doc

./usr/share/doc/gerrit

./usr/share/doc/gerrit/changelog.gz

So what is happening is that when an empty /var/gerrit/etc is bind-mounted from the host, the special gerrit.config file from the deb package is no longer available inside the container and gerrit-init generates a new one (which does not display the nice welcome page and does not automatically create an admin user).

I tried doing what you mentioned above -- putting a copy of the special gerrit.config in the var-gerrit-etc directory on the host -- and can confirm that this gives the same first-run experience (i.e. it is the same as when there are no bind mounts).

I think this deserves some mention in the section "Using persistent volumes" at https://gerrit.googlesource.com/docker-gerrit.  I will open a review.