Open orfeas-k opened 2 months ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-6128.
This message was autogenerated
Until Kubeflow 1.8, centraldashboard image was built using node 14.x.x verion which corresponds to npm
version 6. Looking at the same part of the docs, it turns out that:
If npm was invoked with root privileges, then it will change the uid to the user account or uid specified by the user config, which defaults to
nobody
. Set theunsafe-perm
flag to run scripts with root privileges.
We need to confirm user nobody
permissions in order to be certain this change is the root cause, but since in 1.9 Node version in the image was bumped to version 16 where this behaviour changed, it looks like this is what likely causes the insufficiency in user permissions.
What is still a mystery why we 've seen the charm working with 1.9 upstream image without any changes, although very rarely.
Bug Description
Following up from #222, we noticed that when the charm is run with the upstream image, it exits because the
npm run serve
does not have the required permissions. This renders it unable to write logs at/root/.npm/logs
directory and thus exits with error code243
.As explained in https://github.com/canonical/kubeflow-dashboard-operator/issues/222#issuecomment-2277782508, the pebble container command
npm start
is changing which user is runningnpm run serve
. This is due to a native npm behaviour whereA proper fix would be to ensure user
node
(or 1000:1000 as the logs below suggest) has read/write permissions to/root/.npm/_logs
before starting the service.Workaround
A workaround to this would be to modify the pebble container command to
npm run serve
. This way, we 'll avoid npm running another script (ienpm start
runningnpm run serve
), thusnpm run serve
(called by Pebble) will run as root and have all the permissions it needs.To Reproduce
Environment
Microk8s 1.29 Juju 3.4.4
Relevant Log Output
Additional Context
No response