Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose Go as programming language for installer #39

Open
0xE282B0 opened this issue Aug 22, 2023 · 3 comments · May be fixed by #46
Open

Propose Go as programming language for installer #39

0xE282B0 opened this issue Aug 22, 2023 · 3 comments · May be fixed by #46

Comments

@0xE282B0
Copy link
Member

As the installation procedures for our software project continue to evolve and become more complex, it has become apparent that our current shell script installer is no longer sufficient. Maintaining the existing installer has become increasingly challenging, and it lacks the robustness required for a seamless installation experience.

Proposal:
In light of these challenges, I propose that we migrate our installer to the Go programming language. This transition to Go would offer several advantages:

  1. Enhanced Robustness: Go is known for its robust error handling and built-in concurrency support. This would result in a more reliable installer, reducing the risk of installation failures and errors.

  2. Ease of Maintenance: Go code tends to be clean, readable, and easy to maintain. With the growing complexity of our installation procedures, this change would make it simpler to adapt and update our installer as needed.

  3. Cross-Platform Compatibility: Go can cross-compile for various platforms, ensuring that our installer can seamlessly run on a wide range of operating systems, thereby expanding our software's reach.

  4. Short Compile Time: Go's short compilation times enable quick iteration and development, making it easier to implement changes and improvements to the installer.

  5. Static Binaries: Go produces statically linked binaries, which can be run in containers without relying on the host operating system. This provides a more consistent and container-friendly installation experience.

Scope of Work:

  • Create a new installer using the Go programming language.
  • Migrate existing functionality from the shell script installer to the Go-based installer.
  • Ensure that the new installer supports all the platforms and Kubernetes distributions that are currently supported
  • Implement robust error handling and user-friendly feedback during the installation process.
  • Provide clear documentation and usage instructions for the new installer.

Benefits:

  • Improved extensibility and contributor experience.
  • Reduced maintenance overhead for the installer.
  • Increased compatibility and flexibility for running our software on various platforms.

Additional Considerations:
This proposal aligns with @phyrog suggestion to utilize Go for our installer, taking advantage of its strengths to address the evolving needs of our software installation process.

Please feel free to provide feedback and suggestions on this proposal. Your input will be valuable in shaping the future direction of our installer.

@Mossaka
Copy link
Contributor

Mossaka commented Aug 23, 2023

Or choose Rust as the programming language for implementing the installer. 😎

@phyrog phyrog linked a pull request Sep 28, 2023 that will close this issue
@No9
Copy link

No9 commented Sep 29, 2023

There's a rust version of this repo over here - https://github.com/knawd/deployer
I put it together a few months back as I had a requirement for

  1. AWS Linux
  2. Arm support
  3. A signed helm package
  4. node WASM runtime
  5. OpenShift compatibility
  6. UBI based Images
  7. Automated knative support [edit]

@0xE282B0 not looking to duplicate work or add unnecessary confusion to the eco-system so once the go installer lands would you be interested in the items above as a PR (maybe not 4 as it's very experimental) as they are build/helm related and we can go forward with this installer?

@0xE282B0
Copy link
Member Author

Hi @No9,
We had an internal hackathon yesterday to start with the Go installer: #46

We are currently working on some architectural changes. The bash-based v0.2.0 installer was bundled with the binaries it installed (pretty much like knawd), which in our case resulted in a huge installer image that became increasingly complex. Originally, KWasm was intended to be a lab where you could try all kinds of wasm runtimes on Kubernetes, but it turned out that in most use cases only one or two runtimes are needed.

In v0.3.0 we focused on container shims based on the runwasi project and removed crun support to simplify the installation process. However, the WasmEdge shim is capable of running the crun+wasmedge images and can be used as a drop-in replacement for the use cases we know of. Installing container runtimes like crun or youki is on the roadmap, as well as CRI-O based K8s distributions like OCI OKE or OpenShift, but we currently have no one with that use case. So it is not a high priority. I'd be happy to hear about use cases on these K8s distributions.

Your requirements seem to fit well:

  1. We support Amazon Linux 2 on AWS EKS clusters and many others v0.3.0 Test Matrix #43
  2. We support Arm64 and Amd64
  3. No signed helm packages, but we are working on image signing. We can also work with Helm artifacts.
  4. RE: Node WASM runtime, we are currently experimenting with using bun as a wasi runtime: https://bun.sh/docs/runtime/loaders#wasm
  5. Support for CRI-O based K8s distros is an interesting topic. I have experimented with using youki to run the runwasi shims on OpenShift, but need to upstream the changes to make it usable.
  6. It has been a long time since I last used Universal Base Images. How do they fit into K8's wasm runtimes? I usually build my wasm images from scratch.
  7. Knative support sounds interesting, although I don't know what I would have to customize.

It looks like you're more used to the RedHat container stack, I'd love to see you bring your knowledge to this project!

We have a Slack channel in the CNCF Slack where we can discuss the details:
https://cloud-native.slack.com/archives/C05P2KNK7RV

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants