Proposal of a new official Docker image

[Luca Milanesio]

Hi Gerrit Community,

a lot of clients complained about the lack of information contained in the current DockerHub distribution of Gerrit Code Review.

After digging into the issue, I've realised that:

1. DockerHub is tightly integrated only with GitHub and BitBucket: no ability to fetch info from other Git repos

2. Having a generated Dockerfile is a visibility issue

3. We don't give enough information on how move from the out-of-the-box demo setup to a typical PostgreSQL / LDAP setup

I've created as test-drive:

- https://github.com/GerritCodeReview/docker-gerrit

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

The new organisation should address all the three issues mentioned above.

If you guys like the idea, we can create a brand-new 'docker-gerrit' project on gerrit-review.googlesource.com so that the docker-gerrit repo on GitHub can be fed by Gerrit Code Review changes.

Feedback is more than welcome :-)

Luca.

[Darragh Bailey]

Be good to have an official one, been working off of https://github.com/openfrontier/docker-gerrit with some additional custom scripts added. Perhaps that might be a useful starting reference?

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

--
--
To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Milanesio]

Hi Darragh,

I have actually proposed to them to contribute their Docker image to the community, but had no feedback since then.

I know we could simply fork it, but you know, it is not nice to be "a fork" and keeping up-to-date with their source all the times.

I like merging, not forking :-)

I have ben exactly inspired by their README.md to fill the gaps in the GerritForge's current Docker images: I am not convinced though of the complexity they have introduced in the openfrontier/gerrit and their complex scripting :-(

See this: https://github.com/openfrontier/docker-gerrit/blob/master/gerrit-entrypoint.sh

I see many issues with their approach:

- there is a complex wrapping script on top of Gerrit: yet another thing to manage, document and support

- manages the installation of plugins: why not just using the plugin-manager for that?

- wraps most of settings in gerrit.config as environment variables: why not just mounting an external /etc?

- manages re-indexing and upgrades at init: quite dangerous to have in production, isn't it?

I believe what people like in their Docker image is the clarity of instructions given in the README.md for simple scenarios, such as DB + LDAP configuration.

But I may be wrong :-)

Luca.

[Darragh Bailey]

Hi Luca,

I guess it depends on your usage, we have two different development environments, a docker-compose based one that utilises env vars, and a vagrant puppet based one that used the same image but switches to managing the etc area via puppet.

The second one takes longer to stand up, 2 minutes for the docker compose versus 16 for the vagrant puppet env, but it is standing up a complete ci infrastructure using vms.

I agree about the additional complexity, however in looking at moving to fully container native setup (we not actually there yet) being able to configure via env variables is definitely easier to get started, and needing to have something else build a suitable volume to be passed to swarm/kubernetes to mount under /etc is a big step up.

I see use cases divided into phases:

* trying out/investigation

* usage within simple dev environment

* production (and complex dev envs)

The openfrontier image covers the first two fine, the last not so well, but usually if the first two are too difficult or require too much work to get going with unlikely to make it to the third use case anyway unless you were already committed to using Gerrit.

I see there being two main options, 2 different images to cover the easy to get going or use in production, or one where it's straight forward to switch to managing the config/upgrade in production using something else.

We've opted for the latter in wrapping the openfrontier image with our own entry point to decide whether to call their script or rely on the cfg mgmt to have done it's job. So we have the same image but handle the config differently as needed.

We may get to the point where an image without the scripts would work fine for production, and wrap that with an image for the compose env that adds in such scripts, but might not be suitable for people getting started with Gerrit, so it's possibly not a great starting point for an official image unless you're thinking of doing the two flavours approach.

ymmv

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

[Luca Milanesio]

Hi Darragh,

that's very interesting feedback: it seems to me that the env-var based environment is only for testing / trial.

See below my feedback:

On 20 Aug 2017, at 13:49, Darragh Bailey <daragh...@gmail.com> wrote:

Hi Luca,

I guess it depends on your usage, we have two different development environments, a docker-compose based one that utilises env vars, and a vagrant puppet based one that used the same image but switches to managing the etc area via puppet.

The second one takes longer to stand up, 2 minutes for the docker compose versus 16 for the vagrant puppet env, but it is standing up a complete ci infrastructure using vms.

I agree about the additional complexity, however in looking at moving to fully container native setup (we not actually there yet) being able to configure via env variables is definitely easier to get started, and needing to have something else build a suitable volume to be passed to swarm/kubernetes to mount under /etc is a big step up.

But let's assume we allow an pure env-based setup, how would you setup a proper Gerrit environment without having to define and manage a volume system?

The /index and /git directories cannot be lost across restarts and the built-in volume management in Docker isn't enough :-(

I see use cases divided into phases:

* trying out/investigation

* usage within simple dev environment

* production (and complex dev envs)

The openfrontier image covers the first two fine

With the first, I am with you and I have an idea: why don't we define the concept of "configuration templates" which contain unexpanded placeholders (e.g. $LDAP_SERVER) which are then expanded via env-vars at startup?

The startup script is unaware of that: you just pass the template and the startup script will just expand it.

In your "derived" Dockerfile you can then easily customise your templates to do what makes sense to you.

How does it sound?

With second use-case, how do you manage the persistence of the Git repos and Lucene Index without an external volume?

, the last not so well, but usually if the first two are too difficult or require too much work to get going with unlikely to make it to the third use case anyway unless you were already committed to using Gerrit.

Agreed, the first reason for exposing a Docker image is ease adoption of the people who is getting started with Gerrit and haven't decided yet if they want to use it or not.

However, I see clients that have committed to Gerrit a long a ago and are looking at managing it "as a service" and scale it easily.

There is then space for option three as well :-)

I see there being two main options, 2 different images to cover the easy to get going or use in production, or one where it's straight forward to switch to managing the config/upgrade in production using something else.

I don't like the idea of having different images, but rather one image with the ability to be extended with additional configuration templates.

We've opted for the latter in wrapping the openfrontier image with our own entry point to decide whether to call their script or rely on the cfg mgmt to have done it's job. So we have the same image but handle the config differently as needed.

So, at the end of the day, you have your own image, not sure how much you then rely on the original super-complex script.

The problem with their wrapper script isn't only its inherent complexity, but the cost of keeping it up to and and properly documented.

Gerrit is evolving very fast, it isn't easy and suitable to make a fully featured wrapper script to cover its entire functionality.

Templating is way simpler because the script is independent from the template.

Having configuration templates is something we liked anyway in Gerrit because most of the initial users are struggling to find the "perfect combination" for their configs.

We may get to the point where an image without the scripts would work fine for production, and wrap that with an image for the compose env that adds in such scripts, but might not be suitable for people getting started with Gerrit, so it's possibly not a great starting point for an official image unless you're thinking of doing the two flavours approach.

Still need to understand how you'd manage the /git and /index persistence though, can you share your views?

[lucamilanesio]

Any additional feedback? What do you think about the concept of "Gerrit Configuration Templates"?

The templating idea would be really useful *beyond* the scope of a Gerrit Docker image.

Luca.

[Darragh Bailey]

Hi Luca,

On 20 August 2017 at 15:36, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hi Darragh,

that's very interesting feedback: it seems to me that the env-var based environment is only for testing / trial.

See below my feedback:

On 20 Aug 2017, at 13:49, Darragh Bailey <daragh...@gmail.com> wrote:

Hi Luca,

I guess it depends on your usage, we have two different development environments, a docker-compose based one that utilises env vars, and a vagrant puppet based one that used the same image but switches to managing the etc area via puppet.

The second one takes longer to stand up, 2 minutes for the docker compose versus 16 for the vagrant puppet env, but it is standing up a complete ci infrastructure using vms.

I agree about the additional complexity, however in looking at moving to fully container native setup (we not actually there yet) being able to configure via env variables is definitely easier to get started, and needing to have something else build a suitable volume to be passed to swarm/kubernetes to mount under /etc is a big step up.

But let's assume we allow an pure env-based setup, how would you setup a proper Gerrit environment without having to define and manage a volume system?

The /index and /git directories cannot be lost across restarts and the built-in volume management in Docker isn't enough :-(

As the openfrontier Dockerfile configures the review_site path as a volume, using docker-compose we just provide a nice name for the volume that is easy to lookup.

For our production env, we have network attached storage (3par system) with a view to having kubernetes detach and reattach the lun as needed to the correct physical host if needing to restart the container elsewhere. At the moment we manually managing which host the luns are mounted onto and then doing a simple host volume mount into the container.

In each case we're mounting the entire review_site folder so everything under it is persisted across restarts.

 

I see use cases divided into phases:

* trying out/investigation

* usage within simple dev environment

* production (and complex dev envs)

The openfrontier image covers the first two fine

With the first, I am with you and I have an idea: why don't we define the concept of "configuration templates" which contain unexpanded placeholders (e.g. $LDAP_SERVER) which are then expanded via env-vars at startup?

The startup script is unaware of that: you just pass the template and the startup script will just expand it.

In your "derived" Dockerfile you can then easily customise your templates to do what makes sense to you.

How does it sound?

That sounds great, if Gerrit came with builtin evaluation of configuration using env vars, it would reduce the need for custom scripts.

Is there any concerns around putting security values into ENV variables though? And are those visible to anything running within Gerrit that has access to query for the environment or is that a moot point because anything with that access could query for the secure.config contents anyway?

 

With second use-case, how do you manage the persistence of the Git repos and Lucene Index without an external volume?

We didn't, the compose env uses a plain docker volume (this is intended to be destroyed completely and rebuilt from scratch on dev machines most of the time, vagrant puppet env uses a directory on the host VM to mimic productions use of 3par luns mounted on the host

 

, the last not so well, but usually if the first two are too difficult or require too much work to get going with unlikely to make it to the third use case anyway unless you were already committed to using Gerrit.

Agreed, the first reason for exposing a Docker image is ease adoption of the people who is getting started with Gerrit and haven't decided yet if they want to use it or not.

However, I see clients that have committed to Gerrit a long a ago and are looking at managing it "as a service" and scale it easily.

There is then space for option three as well :-)

True, but usually if there are special needs at that point people are willing to wrap or write from scratch. Getting to that point is definitely more important.

 

I see there being two main options, 2 different images to cover the easy to get going or use in production, or one where it's straight forward to switch to managing the config/upgrade in production using something else.

I don't like the idea of having different images, but rather one image with the ability to be extended with additional configuration templates.

That would definitely be more preferable.

 

We've opted for the latter in wrapping the openfrontier image with our own entry point to decide whether to call their script or rely on the cfg mgmt to have done it's job. So we have the same image but handle the config differently as needed.

So, at the end of the day, you have your own image, not sure how much you then rely on the original super-complex script.

The problem with their wrapper script isn't only its inherent complexity, but the cost of keeping it up to and and properly documented.

Gerrit is evolving very fast, it isn't easy and suitable to make a fully featured wrapper script to cover its entire functionality.

Templating is way simpler because the script is independent from the template.

Having configuration templates is something we liked anyway in Gerrit because most of the initial users are struggling to find the "perfect combination" for their configs.

Definitely like the direction your going.

Passing through configuration in the docker world appears to be, either the application supports retrieving it's configuration information in a dynamic manner from environment or something like etcd, or it any docker image will need to provide an entrypoint to run something to do that for it.

We may get to the point where an image without the scripts would work fine for production, and wrap that with an image for the compose env that adds in such scripts, but might not be suitable for people getting started with Gerrit, so it's possibly not a great starting point for an official image unless you're thinking of doing the two flavours approach.

Still need to understand how you'd manage the /git and /index persistence though, can you share your views?

Hopefully I've answered that as well as can do so above.

--

[Luca Milanesio]

On 21 Aug 2017, at 16:11, Darragh Bailey <daragh...@gmail.com> wrote:

Hi Luca,

On 20 August 2017 at 15:36, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hi Darragh,

that's very interesting feedback: it seems to me that the env-var based environment is only for testing / trial.

See below my feedback:

On 20 Aug 2017, at 13:49, Darragh Bailey <daragh...@gmail.com> wrote:

Hi Luca,

I guess it depends on your usage, we have two different development environments, a docker-compose based one that utilises env vars, and a vagrant puppet based one that used the same image but switches to managing the etc area via puppet.

The second one takes longer to stand up, 2 minutes for the docker compose versus 16 for the vagrant puppet env, but it is standing up a complete ci infrastructure using vms.

I agree about the additional complexity, however in looking at moving to fully container native setup (we not actually there yet) being able to configure via env variables is definitely easier to get started, and needing to have something else build a suitable volume to be passed to swarm/kubernetes to mount under /etc is a big step up.

But let's assume we allow an pure env-based setup, how would you setup a proper Gerrit environment without having to define and manage a volume system?

The /index and /git directories cannot be lost across restarts and the built-in volume management in Docker isn't enough :-(

As the openfrontier Dockerfile configures the review_site path as a volume, using docker-compose we just provide a nice name for the volume that is easy to lookup.

The entire review_site path seems a bit too much for me, you've got lots of temp stuff you don't want to keep across restarts.

Additionally, it would be nice to have embedded a Log4J with a logback (or similar) logger to offload all the logging outside the VM and pushed to an ELK stack.

For our production env, we have network attached storage (3par system) with a view to having kubernetes detach and reattach the lun as needed to the correct physical host if needing to restart the container elsewhere. At the moment we manually managing which host the luns are mounted onto and then doing a simple host volume mount into the container.

In each case we're mounting the entire review_site folder so everything under it is persisted across restarts.

Makes sense, but see above, you may not want to keep the entire review_site.

Another thing that makes a lot of sense is to rely on ES as indexing system rather than Lucene for a Docker-based setup.

 

I see use cases divided into phases:

* trying out/investigation

* usage within simple dev environment

* production (and complex dev envs)

The openfrontier image covers the first two fine

With the first, I am with you and I have an idea: why don't we define the concept of "configuration templates" which contain unexpanded placeholders (e.g. $LDAP_SERVER) which are then expanded via env-vars at startup?

The startup script is unaware of that: you just pass the template and the startup script will just expand it.

In your "derived" Dockerfile you can then easily customise your templates to do what makes sense to you.

How does it sound?

That sounds great, if Gerrit came with builtin evaluation of configuration using env vars, it would reduce the need for custom scripts.

Is there any concerns around putting security values into ENV variables though? And are those visible to anything running within Gerrit that has access to query for the environment or is that a moot point because anything with that access could query for the secure.config contents anyway?

Yes, having a cleartext secure.config isn't more secure than a secret in an environment variable.

If you are keen on security, you need to define a secure-store provider and then just put the encrypted secret into the environment variable.

The value is going to be useless anyway without the encryption key :-)

 

With second use-case, how do you manage the persistence of the Git repos and Lucene Index without an external volume?

We didn't, the compose env uses a plain docker volume (this is intended to be destroyed completely and rebuilt from scratch on dev machines most of the time, vagrant puppet env uses a directory on the host VM to mimic productions use of 3par luns mounted on the host

 

, the last not so well, but usually if the first two are too difficult or require too much work to get going with unlikely to make it to the third use case anyway unless you were already committed to using Gerrit.

Agreed, the first reason for exposing a Docker image is ease adoption of the people who is getting started with Gerrit and haven't decided yet if they want to use it or not.

However, I see clients that have committed to Gerrit a long a ago and are looking at managing it "as a service" and scale it easily.

There is then space for option three as well :-)

True, but usually if there are special needs at that point people are willing to wrap or write from scratch. Getting to that point is definitely more important.

In a super-organised world, yes. However, a company may grow too quickly and then realise that the "pet-setup" of Gerrit has grown and you are left with hundreds of users with a very unstable setup.

Having a "production-setup" based on Docker is going to be very interesting IMHO.

Think about for instance zero-downtime, blue-green upgrades, elastic scaling with multi-master ... Docker is going to help a lot :-)

 

I see there being two main options, 2 different images to cover the easy to get going or use in production, or one where it's straight forward to switch to managing the config/upgrade in production using something else.

I don't like the idea of having different images, but rather one image with the ability to be extended with additional configuration templates.

That would definitely be more preferable.

 

We've opted for the latter in wrapping the openfrontier image with our own entry point to decide whether to call their script or rely on the cfg mgmt to have done it's job. So we have the same image but handle the config differently as needed.

So, at the end of the day, you have your own image, not sure how much you then rely on the original super-complex script.

The problem with their wrapper script isn't only its inherent complexity, but the cost of keeping it up to and and properly documented.

Gerrit is evolving very fast, it isn't easy and suitable to make a fully featured wrapper script to cover its entire functionality.

Templating is way simpler because the script is independent from the template.

Having configuration templates is something we liked anyway in Gerrit because most of the initial users are struggling to find the "perfect combination" for their configs.

Definitely like the direction your going.

Passing through configuration in the docker world appears to be, either the application supports retrieving it's configuration information in a dynamic manner from environment or something like etcd, or it any docker image will need to provide an entrypoint to run something to do that for it.

Yes, I see the same pattern in many other Docker images.

Let's see if the templating idea works in the Gerrit world :-) and people are keen to keep it up-to-date.

We may get to the point where an image without the scripts would work fine for production, and wrap that with an image for the compose env that adds in such scripts, but might not be suitable for people getting started with Gerrit, so it's possibly not a great starting point for an official image unless you're thinking of doing the two flavours approach.

Still need to understand how you'd manage the /git and /index persistence though, can you share your views?

Hopefully I've answered that as well as can do so above.

Yes, thanks.

[Darragh Bailey]

On 21 August 2017 at 16:24, Luca Milanesio <luca.mi...@gmail.com> wrote:

As the openfrontier Dockerfile configures the review_site path as a volume, using docker-compose we just provide a nice name for the volume that is easy to lookup.

The entire review_site path seems a bit too much for me, you've got lots of temp stuff you don't want to keep across restarts.

Additionally, it would be nice to have embedded a Log4J with a logback (or similar) logger to offload all the logging outside the VM and pushed to an ELK stack.

True, but again that's possibly a step up for most people to start with and we've seen some interesting (read annoying) behaviour if you have anything used to do writes to a container root as opposed to a volume, expect to see memory being consumed, so your process will want to be good at cleaning up any temp files subsequently.

The other useful area to preserve between restarts is the location that java melody writes to, as that will allow reviewing of behaviour across restarts. So potentially that plugin and maybe a few others might need to be more considerate as to where they write to.

 

For our production env, we have network attached storage (3par system) with a view to having kubernetes detach and reattach the lun as needed to the correct physical host if needing to restart the container elsewhere. At the moment we manually managing which host the luns are mounted onto and then doing a simple host volume mount into the container.

In each case we're mounting the entire review_site folder so everything under it is persisted across restarts.

Makes sense, but see above, you may not want to keep the entire review_site.

Another thing that makes a lot of sense is to rely on ES as indexing system rather than Lucene for a Docker-based setup.

Starting to sound like you might want to provide some example docker-compose configs to go along with this.

 

That sounds great, if Gerrit came with builtin evaluation of configuration using env vars, it would reduce the need for custom scripts.

Is there any concerns around putting security values into ENV variables though? And are those visible to anything running within Gerrit that has access to query for the environment or is that a moot point because anything with that access could query for the secure.config contents anyway?

Yes, having a cleartext secure.config isn't more secure than a secret in an environment variable.

If you are keen on security, you need to define a secure-store provider and then just put the encrypted secret into the environment variable.

The value is going to be useless anyway without the encryption key :-)

Thanks, that's what I suspected, it just wasn't clear how far the environment from the Docker container would be inherited/accessible into process/threads started in Gerrit when discussing this with security people.

 

True, but usually if there are special needs at that point people are willing to wrap or write from scratch. Getting to that point is definitely more important.

In a super-organised world, yes. However, a company may grow too quickly and then realise that the "pet-setup" of Gerrit has grown and you are left with hundreds of users with a very unstable setup.

Having a "production-setup" based on Docker is going to be very interesting IMHO.

Think about for instance zero-downtime, blue-green upgrades, elastic scaling with multi-master ... Docker is going to help a lot :-)

As long as I don't need a bunch of software to spin up a docker container of gerrit for doing something like testing with any config tweaks, workflow behaviour with ACL changes, new plugins, etc, ;-)

I'm hopeful that both use cases can be catered for

 

It's sounding like some changes are coming down the pipeline that will make it easier to containerize Gerrit, which will make for a cleaner docker image and better experiment/production experience as well. Looking forward to seeing the improvements and hopefully being able to help if possible!

[Luca Milanesio]

On 21 Aug 2017, at 16:43, Darragh Bailey <daragh...@gmail.com> wrote:

On 21 August 2017 at 16:24, Luca Milanesio <luca.mi...@gmail.com> wrote:

As the openfrontier Dockerfile configures the review_site path as a volume, using docker-compose we just provide a nice name for the volume that is easy to lookup.

The entire review_site path seems a bit too much for me, you've got lots of temp stuff you don't want to keep across restarts.

Additionally, it would be nice to have embedded a Log4J with a logback (or similar) logger to offload all the logging outside the VM and pushed to an ELK stack.

True, but again that's possibly a step up for most people to start with and we've seen some interesting (read annoying) behaviour if you have anything used to do writes to a container root as opposed to a volume, expect to see memory being consumed, so your process will want to be good at cleaning up any temp files subsequently.

The other useful area to preserve between restarts is the location that java melody writes to, as that will allow reviewing of behaviour across restarts. So potentially that plugin and maybe a few others might need to be more considerate as to where they write to.

OMG Yes ! JavaMelody stores its RDD files under /tmp ... and after a Docker restart ... puff ! Gone.

@DavidO I believe it is configurable in JavaMelody isn't it? Do we just need to expose it in the Gerrit plugin?

 

For our production env, we have network attached storage (3par system) with a view to having kubernetes detach and reattach the lun as needed to the correct physical host if needing to restart the container elsewhere. At the moment we manually managing which host the luns are mounted onto and then doing a simple host volume mount into the container.

In each case we're mounting the entire review_site folder so everything under it is persisted across restarts.

Makes sense, but see above, you may not want to keep the entire review_site.

Another thing that makes a lot of sense is to rely on ES as indexing system rather than Lucene for a Docker-based setup.

Starting to sound like you might want to provide some example docker-compose configs to go along with this.

Yes, Gerrit without any "companion" would work only in the default DEVELOPMENT_BECOME_ANY_ACCOUNT setup.

You need to give a bit more to it: a docker-compose.yaml sample is definitely needed.

 

That sounds great, if Gerrit came with builtin evaluation of configuration using env vars, it would reduce the need for custom scripts.

Is there any concerns around putting security values into ENV variables though? And are those visible to anything running within Gerrit that has access to query for the environment or is that a moot point because anything with that access could query for the secure.config contents anyway?

Yes, having a cleartext secure.config isn't more secure than a secret in an environment variable.

If you are keen on security, you need to define a secure-store provider and then just put the encrypted secret into the environment variable.

The value is going to be useless anyway without the encryption key :-)

Thanks, that's what I suspected, it just wasn't clear how far the environment from the Docker container would be inherited/accessible into process/threads started in Gerrit when discussing this with security people.

The password is decrypted only when is used inside Gerrit JVM stack. Unless you have access to the JVM stack at that time, you won't see the secrets in cleartext.

However, some parts of Gerrit JVM may keep a copy in the heap ... and that would be an issue, regardless of the use of Docker.

 

True, but usually if there are special needs at that point people are willing to wrap or write from scratch. Getting to that point is definitely more important.

In a super-organised world, yes. However, a company may grow too quickly and then realise that the "pet-setup" of Gerrit has grown and you are left with hundreds of users with a very unstable setup.

Having a "production-setup" based on Docker is going to be very interesting IMHO.

Think about for instance zero-downtime, blue-green upgrades, elastic scaling with multi-master ... Docker is going to help a lot :-)

As long as I don't need a bunch of software to spin up a docker container of gerrit for doing something like testing with any config tweaks, workflow behaviour with ACL changes, new plugins, etc, ;-)

Config tweaks? => you just use an alternate template

Workflow? => it is defined in the refs/meta/config/rules.pl

ACL? => they are in the refs/meta/config/project.config

Plugins? => you have the plugin-manager which is super-super-simple

We should be good then :-)

I'm hopeful that both use cases can be catered for

 

It's sounding like some changes are coming down the pipeline that will make it easier to containerize Gerrit, which will make for a cleaner docker image and better experiment/production experience as well. Looking forward to seeing the improvements and hopefully being able to help if possible!

+1

[דוד אוסטרובסקי‎]

2017-08-21 17:50 GMT+02:00 Luca Milanesio <luca.mi...@gmail.com>:

On 21 Aug 2017, at 16:43, Darragh Bailey <daragh...@gmail.com> wrote:

On 21 August 2017 at 16:24, Luca Milanesio <luca.mi...@gmail.com> wrote:

As the openfrontier Dockerfile configures the review_site path as a volume, using docker-compose we just provide a nice name for the volume that is easy to lookup.

The entire review_site path seems a bit too much for me, you've got lots of temp stuff you don't want to keep across restarts.

Additionally, it would be nice to have embedded a Log4J with a logback (or similar) logger to offload all the logging outside the VM and pushed to an ELK stack.

True, but again that's possibly a step up for most people to start with and we've seen some interesting (read annoying) behaviour if you have anything used to do writes to a container root as opposed to a volume, expect to see memory being consumed, so your process will want to be good at cleaning up any temp files subsequently.

The other useful area to preserve between restarts is the location that java melody writes to, as that will allow reviewing of behaviour across restarts. So potentially that plugin and maybe a few others might need to be more considerate as to where they write to.

OMG Yes ! JavaMelody stores its RDD files under /tmp ... and after a Docker restart ... puff ! Gone.

@DavidO I believe it is configurable in JavaMelody isn't it? Do we just need to expose it in the Gerrit plugin?

There is this change pending for review, but the review process is staled: [1].

[1] https://gerrit-review.googlesource.com/109374

[Luca Milanesio]

Added myself as reviewer, will have a look. thanks.

Luca.

[Darragh Bailey]

I'll try to sort that patch out this week ;-), just been a bit swamped

[lucamilanesio]

Any further feedback?

@Gerrit maintainers: 

can we create the repository 'docker-gerrit' on gerrit-review..googlesource.com with the content of the current github.com/gerritcodereview/docker-gerrit?

Luca.

[David Pursehouse]

On Thu, Aug 24, 2017 at 1:59 PM lucamilanesio <luca.mi...@gmail.com> wrote:

Any further feedback?

@Gerrit maintainers: 

can we create the repository 'docker-gerrit' on gerrit-review..googlesource.com with the content of the current github.com/gerritcodereview/docker-gerrit?

I've created the repository [1] but have not imported the content from github.  Permissions are given to the group of the same name.

[1] https://gerrit-review.googlesource.com/#/admin/projects/docker-gerrit

 

--
--
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.