markhoerth opened a new issue, #11267:
URL: https://github.com/apache/gravitino/issues/11267
### Version
main branch
### Describe what's wrong
Summary
The Apache Gravitino Helm chart at dev/charts/gravitino/ assumes the
Gravitino server is installed at /opt/gravitino/ in the container image. The
init container scripts, the GRAVITINO_HOME env var, and the default initScript
all hardcode this path. All currently published images verified (1.2.0 and
1.3.0-SNAPSHOT) install Gravitino at /root/gravitino/ instead. A default helm
install against the published image fails with CrashLoopBackOff immediately.
Reproduction
bashhelm install gravitino dev/charts/gravitino/ -n gravitino-test
--create-namespace
kubectl get pods -n gravitino-test
# Pod enters CrashLoopBackOff within seconds
Main container crash log:
cp: target '/opt/gravitino/conf' is not a directory
Start the Gravitino Server
/bin/bash: /opt/gravitino/bin/start-gravitino.sh: No such file or directory
Init container log:
cp: cannot stat '/opt/gravitino/scripts/*': No such file or directory
ls: cannot access '/opt/gravitino/libs/gravitino-server-*': No such file or
directory
Evidence
Published images install Gravitino at /root/gravitino, not /opt/gravitino.
Verified against both 1.3.0-SNAPSHOT and 1.2.0:
$ docker inspect apache/gravitino:1.3.0-SNAPSHOT | jq '.[0].Config |
{Entrypoint, WorkingDir}'
{
"Entrypoint": ["/bin/bash", "/root/gravitino/bin/start-gravitino.sh"],
"WorkingDir": "/root/gravitino"
}
$ docker run --rm --entrypoint=sh apache/gravitino:1.3.0-SNAPSHOT -c \
"find / -name 'gravitino-server-*.jar' 2>/dev/null | head -3"
/root/gravitino/iceberg-rest-server/libs/gravitino-server-common-1.3.0-SNAPSHOT.jar
/root/gravitino/libs/gravitino-server-common-1.3.0-SNAPSHOT.jar
/root/gravitino/libs/gravitino-server-1.3.0-SNAPSHOT.jar
$ docker run --rm --entrypoint=sh apache/gravitino:1.2.0 -c \
"find / -name 'gravitino-server-*.jar' 2>/dev/null | head -3"
/root/gravitino/iceberg-rest-server/libs/gravitino-server-common-1.2.0.jar
/root/gravitino/libs/gravitino-server-common-1.2.0.jar
/root/gravitino/libs/gravitino-server-1.2.0.jar
$ docker run --rm --entrypoint=ls apache/gravitino:1.3.0-SNAPSHOT
/opt/gravitino
ls: cannot access '/opt/gravitino': No such file or directory
The chart hardcodes /opt/gravitino in multiple locations:
dev/charts/gravitino/templates/deployment.yaml — init container cp -r
/opt/gravitino/scripts/* and ls /opt/gravitino/libs/gravitino-server-* lookup,
plus GRAVITINO_HOME=/opt/gravitino env var on the main container
dev/charts/gravitino/values.yaml — entity.storagePath:
/opt/gravitino/data/jdbc and initScript referencing ${GRAVITINO_HOME}/conf and
${GRAVITINO_HOME}/bin/start-gravitino.sh
Affected versions
1.3.0-SNAPSHOT (current)
1.2.0 (verified with same diagnostic)
Likely all currently published image tags
Suggested resolution
Three options. Engineering should pick one.
Option A (preferred): Fix the image build to install at /opt/gravitino. /opt
is the standard Linux convention for self-contained third-party software. /root
is the root user's home directory and a non-standard install location. Aligns
the image with the chart's existing assumption and with Docker community
conventions. No chart change required.
Option B: Update the chart to match the image. Change all /opt/gravitino
references in the chart to /root/gravitino. Smaller change but codifies a
non-standard install location in the chart's contract.
Option C: Parameterize. Add image.gravitinoHome (default /root/gravitino) to
values.yaml, reference it everywhere in templates and the init script.
Customers building custom images at other paths can override. Larger chart
change but most flexible.
Environment
Helm 3.20.2
Docker Desktop Kubernetes v1.34.1
Images tested: apache/gravitino:1.3.0-SNAPSHOT (digest
sha256:dae8023c7f3d...) and apache/gravitino:1.2.0
Host: WSL2 Ubuntu
Notes
A previous instance of this bug was filed and closed in favor of
republishing the SNAPSHOT image. The republished image still installs at
/root/gravitino, so the underlying contract mismatch was never actually
resolved. Reopening with broader scope, since the same crash reproduces against
1.2.0 (a released tag, not a SNAPSHOT).
### Error message and/or stacktrace
NA
### How to reproduce
NA
### Additional context
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
