Agree. Its more confusion. PVC / PV are native to k8s not something part of statefulsets. In fact you _probably_ only need to use Statefulsets for databases. Which is probably going to be abstracted away with Operators.
It's more about roll forward/backward and services with a master+replica or leader election. That PVCs are common in stateful sets is more a symptom than the cause
Yea for sure. Thats why I dropped the term database because thats the exact scenario ( master / replica ) where pod consistency naming,dns, network etc is important for StatefulSet.
Yup and trying to hack your OG jetson Nano to a later linux is very hard due to proprietary linux / nvidia firmware/drivers. Its not a matter of your are on your own for OS upgrades, it straight up wont even be able to use the GPU for cuda. Pretty annoying.
I've recently been down this path and its a messy place thats really the most user unfriendly experience. But at a high level you have two staples models. Stable Diffusion 3 XL and FLux.
There are two main tools ( think ollama ) - Automatic1111 ( gradio like UI ) which only works with stable diffusion models... and ComfyUI ( NodeRed like UI ), where comfy ui supports all models but is harder to set up and learn.
I'd say that the main difference is that openwebui is not so focused on making the product "teams first". Yes, it has users, but access to data like documents uploaded for RAG are shared across all the users in the same workspace.
We are going in a direction where access to data is scoped with permissions. We do it via apps (same as "GPTs" in ChatGPT). As a user you upload documents to an app, and then have an advanced sharing system to control who has can access it.
We will be doubling down on making company documents and data accessible from the app, which we aren't sure it's a priority got Openwebui.
" It also works work existing Kubernetes clusters if just want to use GitOps for some applications. Just make sure that the argocd and glasskube-system namespaces are not yet in use. See: https://github.com/glasskube/gitops-template/ "
I assume this statement is for running this?
glasskube bootstrap git --url <your-repo> --username <org-or-username> --token <your-token>
I think I'd like to understand what the argo cd / git ops template is and how its different than argocd autopilot. Maybe some pictures of how argo is deploying apps. Etc.
IIUC, it's basically "manage your Glasskube packages from Git, thanks to ArgoCD".
The `glasskube install` command does a bunch of stuff that ends up as resources in your Kubernetes cluster, that are then interpreted by the Glasskube operator.
The "Gitops template" make use of ArgoCD and Git to do what `glasskube install` would have done.
Thanks. It sounds more like glasskube is a plugin for ArgoCD IIUC
I am not super thrilled about critical applications like Argo getting a plethora of plugins, otherwise we end up looping back to Jenkins and plugin hell
Off-topic: To be honest, after trying almost all the CI/CD offerings out there, CircleCI, Github Actions, Gitlab CI, Travis, etc... I've started to believe that none of them actually did it better than Jenkins (despite all its flaws).
On-topic: Glasskube isn't really an ArgoCD plugin as it can work standalone, but in 2024, can you really propose a package manager for k8s without having some integration with ArgoCD and GitOps in general?
If you want to migrate, having interoperability between the tools can make the process smoother. And if you don't want to migrate and still benefit from a centralized, curated, audited repository of packages for Kubernetes so that your "Powered by ArgoCD" GitOps are easier to manage, that's what the GitOps template propose.
In Debian, you can just `apt install <that big thing i don't want to write a deploy script for>`. Imagine doing that with the usual big operators you want in your cluster (cert-manager, a hashicorp vault operator, istio or nginx ingress controller or envoy or ...)
FluxCD is fully batteries-included, but the UI (3rd party!) leaves a lot to be desired, and turns off a lot of developers, and as a result makes it difficult to get team buy-in
ArgoCD is missing some critical systems, like how to tell when the underlying image needs updating. There are a number of ways to handle this but it's either a kludge, a plugin, or both. However, the UI is fantastic and very easy to pickup and understand, team buy-in is usually close to 100%
I generally recommend starting with argo, and once the team/project/s have matured, migrate to FluxCD. Eventually you want to lock everyone out of the CD system, but initially people are skeptical and want to understand/watch everything work, especially during debug.
Thanks linkdd. Exactly Glasskube in "GitOps mode" will output these package custom resources as yaml so you can commit them to git and argo pulls these resources from git into the cluster.
I just setup a argo cd autopilot repository https://github.com/pmig/argocd-autopilot as a comparison. Autopilot gives you a great opinionated scaffold for internal applications.
Our template already includes update automations with the renovate integration and easier integration of third party applications.
I mean renovate in github is 1 file and a app integration. It takes very little effort to setup. What exactly do you mean by easier integration of third party apps? Why wouldnt someone just use https://operatorhub.io/. ?
Tldr.: If you are already using open shift, make use of the operator hub, else glasskube is the more lightweight and simpler solution with similar concepts.
sure , but all the operator hubs are just wrappers of the real operator, which is published on their operator hub page, so you can use https://github.com/apache/flink-kubernetes-operator which doesnt require openshift.
Yes, you can get started by executing this commands.
Our bootstrap git sub command is similar to argo cd autopliot. I give it a try right now to be able to better state differences and follow up on this question.
I mean, the whole world was impacted. All they had to do was test this change in a lab with several pcs. Clearly this wasn't a edge case nor a subtle problem. This was clearly a lack of testing.
Leave the spin to the PR people. Their customers pay a great deal of money for 24x7 service, and this wasn’t even a code change but a definition update – a process which should be as well defined and tested as McDonald’s making a hamburger. You wouldn’t excuse getting E. coli from your lunch with “the cook just wanted to go home for the weekend”, and this is a much more expensive service.
reply