[percona] update ps-80 version #17310
Conversation
Diff for 659fade:diff --git a/_bashbrew-cat b/_bashbrew-cat
index 35d4c8b..dac347a 100644
--- a/_bashbrew-cat
+++ b/_bashbrew-cat
@@ -12,8 +12,8 @@ GitCommit: b89efa5f100edacc0ef660cef37975acfaf67326
Directory: percona-server-5.7
File: Dockerfile-dockerhub
-Tags: 8.0.36-28-centos, 8.0-centos, 8-centos, 8.0.36-28, 8.0, 8, ps-8.0.36-28, ps-8.0, ps-8
-GitCommit: 02252c71b5fcf2d2235f7ec0d81940d4f2c45b64
+Tags: 8.0.37-29-centos, 8.0-centos, 8-centos, 8.0.37-29, 8.0, 8, ps-8.0.37-29, ps-8.0, ps-8
+GitCommit: efe9f2a1ebaf673d199c5322c4abf69b782008f6
Directory: percona-server-8.0
Tags: psmdb-4.2.24, psmdb-4.2
diff --git a/_bashbrew-list b/_bashbrew-list
index b19b65a..c16bc85 100644
--- a/_bashbrew-list
+++ b/_bashbrew-list
@@ -12,8 +12,8 @@ percona:8
percona:8-centos
percona:8.0
percona:8.0-centos
-percona:8.0.36-28
-percona:8.0.36-28-centos
+percona:8.0.37-29
+percona:8.0.37-29-centos
percona:centos
percona:psmdb-4.2
percona:psmdb-4.2.24
@@ -30,4 +30,4 @@ percona:ps-5.7
percona:ps-5.7.44
percona:ps-8
percona:ps-8.0
-percona:ps-8.0.36-28
+percona:ps-8.0.37-29
diff --git a/percona_ps-8/Dockerfile b/percona_ps-8/Dockerfile
index 3ccf519..20279c3 100644
--- a/percona_ps-8/Dockerfile
+++ b/percona_ps-8/Dockerfile
@@ -16,16 +16,15 @@ RUN set -ex; \
useradd -u 1001 -r -g 1001 -s /sbin/nologin \
-m -c "Default Application User" mysql
-ENV PS_VERSION 8.0.36-28.1
-ENV MYSQL_SHELL_VERSION 8.0.36-1
+ENV PS_VERSION 8.0.37-29.1
+ENV MYSQL_SHELL_VERSION 8.0.37-1
ENV OS_VER el9
ENV FULL_PERCONA_VERSION "$PS_VERSION.$OS_VER"
ENV FULL_MYSQL_SHELL_VERSION "$MYSQL_SHELL_VERSION.$OS_VER"
ENV PS_REPO release
-ENV PS_TELEMETRY_VERSION 8.0.36-28-1
+ENV PS_TELEMETRY_VERSION 8.0.37-29-1
ENV CALL_HOME_DOWNLOAD_SHA256 5e84d2f1a5d57f44c46e6a1f16794d649d3de09fe8021f0294bc321c89e51068
ENV CALL_HOME_VERSION 0.1
-
# Do not report during Docker image creation.
# Note that doing so, would create telemetry config file
# which would prevent reporting when new container is started.
@@ -36,10 +35,10 @@ ARG PERCONA_TELEMETRY_DISABLE=1
# check repository package signature in secure way
RUN set -ex; \
export GNUPGHOME="$(mktemp -d)"; \
- gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 430BDF5C56E7C94E848EE60C1C4CBDCDCD2EFD2A 99DB70FAE1D7CE227FB6488205B555B38483C65D; \
- gpg --batch --export --armor 430BDF5C56E7C94E848EE60C1C4CBDCDCD2EFD2A > ${GNUPGHOME}/RPM-GPG-KEY-Percona; \
+ gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 4D1BB29D63D98E422B2113B19334A25F8507EFA5 99DB70FAE1D7CE227FB6488205B555B38483C65D; \
+ gpg --batch --export --armor 4D1BB29D63D98E422B2113B19334A25F8507EFA5 > ${GNUPGHOME}/PERCONA-PACKAGING-KEY; \
gpg --batch --export --armor 99DB70FAE1D7CE227FB6488205B555B38483C65D > ${GNUPGHOME}/RPM-GPG-KEY-centosofficial; \
- rpmkeys --import ${GNUPGHOME}/RPM-GPG-KEY-Percona ${GNUPGHOME}/RPM-GPG-KEY-centosofficial; \
+ rpmkeys --import ${GNUPGHOME}/PERCONA-PACKAGING-KEY ${GNUPGHOME}/RPM-GPG-KEY-centosofficial; \
curl -Lf -o /tmp/percona-release.rpm https://repo.percona.com/yum/percona-release-latest.noarch.rpm; \
rpmkeys --checksig /tmp/percona-release.rpm; \
rpm -i /tmp/percona-release.rpm; \
@@ -47,6 +46,7 @@ RUN set -ex; \
rpm --import /etc/pki/rpm-gpg/PERCONA-PACKAGING-KEY; \
percona-release disable all; \
percona-release enable ps-80 ${PS_REPO}; \
+ percona-release enable telemetry ${PS_REPO}; \
percona-release enable mysql-shell ${PS_REPO}
RUN set -ex; \
@@ -64,6 +64,7 @@ RUN set -ex; \
curl \
glibc \
libnghttp2 \
+ openssh \
python3; \
\
dnf -y install \
@@ -108,6 +109,17 @@ RUN set -eux; \
ENV CALL_HOME_OPTIONAL_PARAMS=" -s ${OS_VER}"
COPY ps-entry.sh /docker-entrypoint.sh
+COPY telemetry-agent-supervisor.sh /usr/bin/
+RUN set -ex; \
+ chown mysql /usr/bin/telemetry-agent-supervisor.sh; \
+ chown mysql /usr/bin/percona-telemetry-agent; \
+ chown mysql /usr/local/percona/telemetry/history; \
+ chmod ug+rwx /usr/bin/telemetry-agent-supervisor.sh; \
+ chmod -R go+w /var/log/percona
+ENV PERCONA_TELEMETRY_CHECK_INTERVAL=86400
+ENV PERCONA_TELEMETRY_HISTORY_KEEP_INTERVAL=604800
+ENV PERCONA_TELEMETRY_RESEND_INTERVAL=60
+ENV PERCONA_TELEMETRY_URL=https://check.percona.com/v1/telemetry/GenericReport
ENTRYPOINT ["/docker-entrypoint.sh"]
USER mysql
diff --git a/percona_ps-8/ps-entry.sh b/percona_ps-8/ps-entry.sh
index 8b92cf5..a7fe81b 100755
--- a/percona_ps-8/ps-entry.sh
+++ b/percona_ps-8/ps-entry.sh
@@ -248,7 +245,9 @@ else
CALL_HOME_OPTIONAL_PARAMS+=" -c 2"
fi
-# PERCONA_TELEMETRY_DISABLE is handled at the very beginning of call-home.sh
-/call-home.sh -f "PRODUCT_FAMILY_PS" -v "${PS_TELEMETRY_VERSION}" -d "DOCKER" ${CALL_HOME_OPTIONAL_PARAMS} &> /dev/null || :
-
-exec "$@"
+if [[ ${PERCONA_TELEMETRY_DISABLE} -ne "0" ]]; then
+ exec "$@" --percona_telemetry_disable=1
+else
+ /usr/bin/telemetry-agent-supervisor.sh &
+ exec "$@"
+fi
diff --git a/percona_ps-8/telemetry-agent-supervisor.sh b/percona_ps-8/telemetry-agent-supervisor.sh
new file mode 100644
index 0000000..6ad026e
--- /dev/null
+++ b/percona_ps-8/telemetry-agent-supervisor.sh
@@ -0,0 +1,14 @@
+#!/bin/bash
+
+# phase-0 telemetry
+/call-home.sh -f "PRODUCT_FAMILY_PS" -v "${PS_TELEMETRY_VERSION}" -d "DOCKER" ${CALL_HOME_OPTIONAL_PARAMS} &> /dev/null || :
+
+# phase-1 telemetry
+for i in {1..3}; do
+ /usr/bin/percona-telemetry-agent >> /var/log/percona/telemetry-agent.log 2>> /var/log/percona/telemetry-agent-error.log
+ if [ $? -eq 0 ]; then
+ break
+ fi
+ sleep 5
+done
+sleep infinityRelevant Maintainers:
|
|
What sets -# PERCONA_TELEMETRY_DISABLE is handled at the very beginning of call-home.sh
-/call-home.sh -f "PRODUCT_FAMILY_PS" -v "${PS_TELEMETRY_VERSION}" -d "DOCKER" ${CALL_HOME_OPTIONAL_PARAMS} &> /dev/null || :
-
-exec "$@"
+if [[ ${PERCONA_TELEMETRY_DISABLE} -ne "0" ]]; then
+ exec "$@" --percona_telemetry_disable=1
+else
+ /usr/bin/telemetry-agent-supervisor.sh &
+ exec "$@"
+fiWhy is it necessary for the telemetry script to |
The data collection may be disabled via setting an environment variable PERCONA_TELEMETRY_DISABLE=1 during Linux package installation or Docker container startup. For example, on a Docker container (this action disables the continuous telemetry part as well): |
https://github.com/percona/telemetry-agent?tab=readme-ov-file#continuous-telemetry |
|
To clarify my questions a bit more: The The conditional for the value of the |
|
Errors from GitHub Actions tests:
Review of changes in
|
The second command, i.e. /usr/bin/percona-telemetry-agent runs in the background and has to be always running and will exit only in case the container is killed. In case of any issues, it will try re-starting the percona-telemetry-agent process 3 times. Since percona-telemetry-agent process has to always be running and to avoid any zombie processes being created when the supervisor script exits, we have the supervisor script always running.
No, the percona-telemetry-agent process runs in both conditions, when PERCONA_TELEMETRY_DISABLE is set to "0" and even when PERCONA_TELEMETRY_DISABLE is unintialized. In the condition |
The reason we added a
Sure, Thank you, we shall try replacing chmod/chown commands with the above mentioned ways. |
I am confused by your response. Does Here is the script in question: #!/bin/bash
# phase-0 telemetry
/call-home.sh -f "PRODUCT_FAMILY_PS" -v "${PS_TELEMETRY_VERSION}" -d "DOCKER" ${CALL_HOME_OPTIONAL_PARAMS} &> /dev/null || :
# phase-1 telemetry
for i in {1..3}; do
/usr/bin/percona-telemetry-agent >> /var/log/percona/telemetry-agent.log 2>> /var/log/percona/telemetry-agent-error.log
if [ $? -eq 0 ]; then
break
fi
sleep 5
done
sleep infinity |
|
Either way, and to try and make this more explicitly clear, a generic process supervisor (either in shell or an explicit supervisor tool like supervisord) is unfortunately not going to be acceptable here. |
|
All images specified in |
@tianon and what would be the suggested way? What is the best practice for such situation? |
|
If both processes are necessary and must stay resident/running, a separate container for each or a proper manager/worker model as seen in Apache, HAProxy, NGINX, etc. |
|
@tianon , We followed the official documentation from Docker here which suggests using either a wrapper script or supervisord for managing multiple processes in a container. Our implementation uses a wrapper script ( telemetry-agent-supervisor.sh) as per the guidance, structured like this:
Alternatively, we also explored supervisord which is also mentioned in the above doc,
Also, the docker images you mentioned as a reference, i.e. Apache, HAProxy, NGINX, etc. run one process in entrypoint which forks sub-processes. Since you mentioned that supervisord or a wrapper script is not acceptable, could you kindly clarify what exactly needs to be changed in our approach or any alternative method you would recommend to run multiple processes in a container? |
Without making the telemetry process a child managed by Running multiple processes side by side within a single container is complex and there are many edge cases that we can't always remember and review in PRs to official images. To ensure that all images meet the high quality users expect from Docker Official Images, we restrict them to a single process (aside from those that spawn and manage their own worker processes). Just for clarification as to why multi-process containers are so complex. Here are just a few edges and considerations that are needed for a multi-process container; this list is neither exhaustive nor an acceptance checklist:
|
No description provided.