👋 Hey all, I am Justin Law! I work on AI/ML applications and Kubernetes packaging at a startup called Defense Unicorns 🦄. I have been deploying and using Phoenix for my team of Forward Deployed Engineers so that we can get actionable insights on how our applications and models are performing in both development and production environments. 👀 I am mainly here to snoop around for new developments to Phoenix. ❓ I am currently curious about where I should post my GitHub issues and PRs for more visibility from the OSS Phoenix team. We've merged 2 of mine in recently, but I have 2 more upcoming so that we can improve the Helm deployment more. ℹ️ If anyone wants to discuss more about air-gapped or secure cloud deployments of Phoenix, please let me know - I am still learning and would love to knowledge share with others!
Haha thanks! The equally fun swag and logos is probably one of my favorite parts here Okay, that sounds good to me! Thanks for confirming :)
Welcome Justin! You can always reach the dev team in Phoenix Support if you need any help. Thanks so much your your contributions over the week! Happy to help unblock.
Justin L. i have reviewed your PR, i have concerns on setting the Working Directory, and specifically making it default to "/data". It would make more sense to leave it empty so it can default to whatever $HOME is
I think instead we could add some validation that is persistance is on , we should stop deployment until the user also sets a working directory
A strict securityContext would cause errors in Phoenix, since it can't write to directories it doesn't own as nonroot.
Oh, as in similar to the _helper.tpl validators I added?
Yes
I just updated the PR branch. Let me know if you don't like the validators or new comments regarding workingDir!
Hi Justin L.
I think the comments are great but im more so trying to protect installers who may not know whether they should mess with the securityContext's and how to properly set them, one idea and validator i wrote for example works under the following scenario
helm install phoenix . -f values.yaml --dry-run --set persistence.enabled=true --set postgresql.enabled=false --set securityContext.pod.enabled=true --set securityContext.pod.runAsUser=1000 --set securityContext.pod.fsGroup=1000 --set se
curityContext.pod.runAsGroup=1111and returns warning
Error: INSTALLATION FAILED: execution error at (phoenix-helm/templates/phoenix/pvc.yaml:1:4): INFO: fsGroup (1000) differs from runAsGroup (1111). While this can work (fsGroup is added as supplementary group), consider aligning them for clarity. Set suppressMismatchedGroupWarning=true to acknowledge.what are your thoughts on this pattern
Oh I like that idea a lot! If no security contexts are set, and/or for some reason the user allows root user, then there shouldn't be any issues generally speaking; however, I totally understand if someone does set some security settings that don't allow the Phoenix container to start due to the SQLite DB not being able to create the .phoneix DB at the mountpoint.
