Added possibility to override jars in the mounted volume (mount would be populated with files from the distribution during startup unless they exist)

I've encountered an issue with this approach (or at least an unexpected result).

Right now, in start.sh file we have following line:

cp -r -n /home/tigase/tigase-server/jars.orig/* /home/tigase/tigase-server/jars/

that copies jars to temporary volume, so that use could replace them as needed (ie. to update a single component during testing).

However, if we are using docker compose and we would use:

docker compose pull
docker-compose up --force-recreate --no-deps xmpp

to update docker image of xmpp service and recreate container with this new image (to not remove volumes), it will not remove "temporary volume" that stores jars directory, so at startup cp -r -n will not update jars to the newer versions (as they were there but in older version).

Please note, that in my case I've not configured a custom location (not mounted) for jars volume and it was automatically create and caused an issue as I was expected to have a new version (according to the image hash that I was running) but I've got an old version of a jar being reported in the logs.

I wonder, if it wouldn't be better to remove -n from cp -r -n or parameterize it, so that docker image environment (ie. "DEVELOPMENT") would trigger adding -n option.

Also, it is possible to mount a volume at any mount point in the container and this mount point doesn't need to be defined in a Dockerfile (or its alternative we are using).

That is why I would prefer to revert this change.

@wojtek What do you think?

(argh... "lovely" 1dev removed any association with the commits... :| )

hmm... AFAIR without -n when you would have mounted path it would overwrite your custom files so it's a no-go IMHO. I've tried a couple of things when I was making this change and unfortunately this one, with custom directory and copying was the only one that allowed for custom jars.

As for the compose pull/up. I would recommend doing compose pull/down/up (instead of recreate) but if you prefer using --force-recreate wouldn't --renew-anon-volumes solve the issue here?

Well, it could. I was just unaware that it was required to do anything more than just recreate. I wanted to make it safe, so I preferred not to use down and that caused this issue.

I wonder, if this would impact k8s as well? In theory it shouldn't as pod is not stopped and started but rather killed and recreated... but what about volumes?

And I was suggesting to add -n to the command line if some environment property would be set (conditionally), so it would work in both cases.

Well, it could. I was just unaware that it was required to do anything more than just recreate. I wanted to make it safe, so I preferred not to use down and that caused this issue.

Why down would be not safe? Docker is "funny" sometimes and for example if you do plain pull and then restart (or stop/start) then you would end up with same image being used. Hence, I just use down / up to make sure it's actually updated :)

I wonder, if this would impact k8s as well? In theory it shouldn't as pod is not stopped and started but rather killed and recreated... but what about volumes?

I don't have such extensive knowledge of k8s to answer that. Though, from what I saw, k8s seems to be rather more "destructive" so wiping mostly everything and then recreating…

And I was suggesting to add -n to the command line if some environment property would be set (conditionally), so it would work in both cases.

Well, we could yet another flag (OFF by default) but would that actually solve the issue (any better than using down & up)? Or would just add more complexity (KISS)? The whole mechanism is still kinda non-standard in the end…

Pondering it a bit more: what we want - being able to override certain binaries - maybe we could flip it on the head and expose mount "custom binaries" that would override those in container during startup? (though being able to easily investigate binaries/jars/versions by mounting the directory is quite convenient)

Pondering it a bit more: what we want - being able to override certain binaries - maybe we could flip it on the head and expose mount "custom binaries" that would override those in container during startup?

You mean by copying "jars" from the custom location to the image during startup? instead of copying jars from the image to the location?

I've used this approach before, but I mounted volume and then just exec to container to issue cp manually and it worked quite well.

As for convenience, I agree that what we have is convenient, however, I do not like "cacheing" old jars that we have right now (ie. in mounter "jars" volume I could have old version and I've updated image to test new version - I would end up with old version with a new image... that is slightly confusing).

Also, it is possible to mount a volume at any mount point in the container and this mount point doesn't need to be defined in a Dockerfile (or its alternative we are using).

That is why I would prefer to revert this change.

I was pondering the issue a bit more and this may be the best solution - while full directory is convenient, most of the time we need to override a specific binary (a couple of components) so having (in compose) something like:

    volumes:
      - ./Users/wojtek/dev/tigase/tigase-server/target/tigase-server.jar:/home/tigase/tigase-server/jars/tigase-server.jar

could be simpler/better...

However, on the yet another look, using --renew-anon-volumes should solve the issue as well so I may lean towards recommending it :)

I have no objections, however we should document behavior of our image, so that people would be aware that anon volumes need to be recreated when image is being updated.