Comments URL: https://news.ycombinator.com/item?id=43633707

Points: 9

# Comments: 0

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.

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.

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.

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.

Hope this helps provide some context.

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.

https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-st...

Most of the examples are primarily container-based and the specification reflects that. We will definitely have to do a better job fleshing out the design with alternative invocation image types than OCI/docker. The azure-vm driver is one such (experimental) example.

Hope this helps!

This requires that you have logged in to the registry, pushed the image to the registry and have `docker pull` rights for the image. You could also run a registry locally, push your image there and inspect your registry's storage db. There's just no CLI command to do that.

Every layer understands the command it was run in the Dockerfile to create itself. Just look at `docker history` and have a look at the "CREATED BY" field for human-readable output of the layer metadata, or depending on your graph driver have a look in /var/lib/docker/image/overlay2/imagedb/content/sha256. From there you can reverse-engineer a Dockerfile.

For layers that were not built using `docker build` (e.g. `docker commit`, OCI-compatible image builders), re-creating the exact command that generated that layer is much harder to do. The only information most tools will give you might just be the diff itself.