build: radosgw binaries have been moved to /radosgw directory in gateway's Dockerfiles

[giubacc]

This patch is needed as prerequisite for: #164

Signed-off-by: Giuseppe Baccini giuseppe.baccini@suse.com

Describe your changes

Issue ticket number and link

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• CHANGELOG.md has been updated should there be relevant changes in this PR.

[votdev]

Could you please add an explanation WHY it is necessary and helpful to relocate the binary into a separate directory.

[giubacc]

Could you please add an explanation WHY it is necessary and helpful to relocate the binary into a separate directory.

sure, here the high level description of what the script updating the binaries inside k8s is supposed to do:

# This script should be used while doing development on s3gw's radosgw binaries.
# By calling this script, we patch the s3gw deployment inside k8s as this:
#
# 1) A base image is used,  ghcr.io/aquarist-labs/s3gw:latest (default).
# 2) We create a PVC and a helper copier pod that mounts that PVC.
# 3) We copy the built binaries on the PVC by calling an equivalent `kubectl cp` command
#    on the copier pod.
#
# 4) We mount the same PVC on the s3gw pod at the location where
#    the binaries are expected (/radosgw).
#
# Patching the deployment forces the s3gw pod to restart with the new binaries in place.

The main trick here is point 4, that is basically replacing binaries with the one you have just built.

[votdev]

Could you please add an explanation WHY it is necessary and helpful to relocate the binary into a separate directory.

sure, here the high level description of what the script updating the binaries inside k8s is supposed to do:

# This script should be used while doing development on s3gw's radosgw binaries.
# By calling this script, we patch the s3gw deployment inside k8s as this:
#
# 1) A base image is used,  ghcr.io/aquarist-labs/s3gw:latest (default).
# 2) We create a PVC and a helper copier pod that mounts that PVC.
# 3) We copy the built binaries on the PVC by calling an equivalent `kubectl cp` command
#    on the copier pod.
#
# 4) We mount the same PVC on the s3gw pod at the location where
#    the binaries are expected (/radosgw).
#
# Patching the deployment forces the s3gw pod to restart with the new binaries in place.

The main trick here is point 4, that is basically replacing binaries with the one you have just built.

Make sense. Without a dedicated directory, /usr/bin/ will be replaced which will break the container at the end.

[giubacc]

@jecluis are you fine with these modifications?
Are you seeing any potential trap?

[jecluis]

@jecluis are you fine with these modifications? Are you seeing any potential trap?

Given we are moving the libraries to a path that is not standard, I fear that we might require LD_LIBRARY_PATH to be provided to run the binary. Or find a way to add that path to the ld search path.

[jecluis]

@jecluis are you fine with these modifications? Are you seeing any potential trap?

Given we are moving the libraries to a path that is not standard, I fear that we might require LD_LIBRARY_PATH to be provided to run the binary. Or find a way to add that path to the ld search path.

And now I see you already do that in the dockerfile. Let me think a bit on this.

[giubacc]

@jecluis are you fine with these modifications? Are you seeing any potential trap?

Given we are moving the libraries to a path that is not standard, I fear that we might require LD_LIBRARY_PATH to be provided to run the binary. Or find a way to add that path to the ld search path.

And now I see you already do that in the dockerfile. Let me think a bit on this.

yes, consider that the whole thing has been already tested and it is working; but maybe there are non obvious drawbacks I'm not seeing.

[m-ildefons]

You could do this simpler by also putting /radosgw in the $PATH and calling radosgw without the absolute path in the entrypoint. Then you can just kubectl cp directly into the s3gw container's /radosgw where the persistent volume is mounted. After that just kubectl delete the pod. The new pod that will be started will execute the radosgw from the persistent volume instead. No need for a "copier pod" and no need to move the "normal" radosgw binaries around.

You might even be able to set the environment variables by supplying them in the deployments manifest or kubectl edit the deployment once it is applied to the cluster.

[giubacc]

You could do this simpler by also putting /radosgw in the $PATH and calling radosgw without the absolute path in the entrypoint. Then you can just kubectl cp directly into the s3gw container's /radosgw where the persistent volume is mounted. After that just kubectl delete the pod. The new pod that will be started will execute the radosgw from the persistent volume instead. No need for a "copier pod" and no need to move the "normal" radosgw binaries around.

You might even be able to set the environment variables by supplying them in the deployments manifest or kubectl edit the deployment once it is applied to the cluster.

Ok to implement suggestion nr. 1.
Regarding other suggestions, agree to discuss them, but please comment here instead.
Let's take in account that this doesn't need to be super well designed, it is an helper tool for the developer.
The implementation proposed for sure can be improved, but I'm using it everyday and it does well its job.