This repository has been archived by the owner on May 21, 2024. It is now read-only.
Replies: 1 comment
-
I think there's a lot to be said for this approach. It wasn't the initial plan from a Gitpod point of view, but I think it's probably a better option for an open, self-managed installation. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So, I was going through the installer last night making changes so it could optionally write out the files to a flux structure instead of applying them inside the install script itself and I got to thinking maybe I'm coming about this the wrong way...
how about, the installer stages every file, regardless of target, then folks like me who use flux can leverage the output, folks who might use something else like argo or a homebrew system aren't locked out or trying to get more stuff baked into the installer and the installer could easily then straight after writing the files apply them if a certain flag is set, or just the default and us folks can pass a flag to tell it not to apply them.
This also gives some better debugging for people using standard kubernetes processes but its not being applied properly for whatever reason as they can see what was trying to get applied by the installer.
Then people like me can wrap your installer in a flux script, that then picks up the k8s manifests, applies some more logic for flux or whatever to tie it together and then apply our own setup. This means we're not then polluting the installer with logic for our platforms but also not having to maintain duplicate installers to do different installations.
Thoughts @mrsimonemms ?
Beta Was this translation helpful? Give feedback.
All reactions