The existence of right tools for the job implies the existence of wrong tools for the job. The engineer in GP's story used the wrong tool for the job. That is a people problem. Had he used the right tool for the job, the problem would not have existed. GP wrote their CI stuff in shell to solve a tech problem, not a people problem.
Keep in mind that this discussion is about one's personal project.
The situation changes if you have a small team of maintainers dedicated on a project. But most personal projects won't write a full acceptance suite just to start accepting contributions.
To be fair, simple one-liner changes can be just as impactful as an entire package rewrite. I've reviewed a few one-liners that seemed innocent at the time, but had massive impact downstream.
As the project and the userbase grows, small conditional changes can be the most difficult to test because they require a very specific setup to test and verify.
Often times the only person that can reproduce the issue is the person submitting the PR.
The idea behind the project is to run WebAssembly modules in Kubernetes. You would have to compile your Python script to WebAssembly before it could be executed.
If your WebAssembly module complies with the WebAssembly System Interface, Krustlet can run it.
It's important to note that the WASI standard and wasmtime are still under heavy development. There are some key features (like networking) that are currently missing, but will be made available in future updates.
Maybe a dumb question, but can I run Krustlet in the browser? (maybe via browser WASI polyfill?). Does this mean you could assemble ad-hoc clusters using volunteer browsers? Not saying one _should_, but could you?
Krustlet is not in WebAssembly itself. It's an implementation of kubelet in rust that runs WebAssembly inside WASI or WASCC runtime, not other way around.
Removing a significant piece of the architecture was a large undertaking. There's many parts of the system that required a redesign. Throwing on yet another major piece of work (including developing a new Lua VM from the ground up) would've delayed the release well into next year. Many users just wanted Helm without Tiller.
To provide some perspective, over 80,000 lines of code was changed between 2.16.1 and 3.0.0, including test infrastructure, the architecture, documentation...
We started development on Helm 3 last year in March, shortly after the first Helm Summit in Portland. A complete redesign of the architecture in 20 months time seems pretty par for the course for a project of this size.
I highly suggest giving Helm 3 a try, as much of the release ledger system was overhauled. If you can provide links to the issues you're seeing, that's always helpful too.
Oh, I probably will give it a try. Helm is pretty much inescapable since the community has rallied around using it for distributing manifests. It's just sad to need yet another bespoke tool when the general purpose ones do a fine job.
Helm Classic was introduced at the first KubeCon... Wayyy back in November 2015. Kubernetes 1.1.1 was released earlier that month, and 1.0.0 shipped only 4 months prior to that in July.
Back then, Kubernetes had no concept of a ConfigMap. ReplicationControllers were all the hype (remember those?). The Kubernetes API was changing rapidly. When Helm 2 was being built, we needed an abstraction layer from the Kubernetes API to allow ourselves some room to guarantee backwards compatibility. Tiller was created as that abstraction layer. It provided us with a layer where we could control the input (via gRPC), the output (also via gRPC), and provide some backwards compatibility guarantees to users. We're pretty proud of the fact that Helm has maintained a strong commitment to backwards compatibility since 2.0.0.
Over time, Kubernetes' API layer has become more stable. Helm 3 is our opportunity to refactor out some of those protective layers we put in 4 years ago. Tiller being one of them.
This is not how things work in reality. Many last-mile objects are merged into your Kubernetes resources at the last minute. Service meshes inject sidecar containers into your deployments. The Kubernetes API can update a Service's virtual IP addresses which can change over time. All of these object updates need to be taken into consideration during an upgrade, or you risk disrupting resources running in production.
I'm not saying there isn't a use case for this, it's just that for the most part I prefer dumping what I have from an immutable git commit into the Kube API. If something needs to happen after the fact for governance or injecting sidecars, so be it but that is out of the scope of what I am deploying.
Then that's fine. If no updates were made to the resource since the last update, then the patch will not look at the live state.
I highly suggest re-reading the FAQ front-to-back on this subject. I spent a lot of time explaining the details on this subject. If you have any questions/concerns, we are always happy to discuss further on github.
To take a step back... we're discussing a personal opinion on how to manage things compared to what k8s has documented and what's happening with other tools like service meshes.
I respect what someone has as an opinion. I just would like others to know where the opinion differs from the docs and tools out there. People can make their own choices.
