You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have contributed some features and refactoring to wesher in the past and have been using it for production clusters everyday since. Little to say I have come to love this project, its simple architecture and philosophy.
As a separate project I have been building a Kubernetes distribution, starting with duct-taped proof of concepts binding wesher and k3s together as independent processes. I have reached a point where binding the pieces together is better achieved in Golang directly, benefiting from the nice feats of Goroutine scheduler and memory manager.
In the end, I would very much like to embed wesher as a library for setting up the mesh vpn. I would use the wireguard abstractions and common types but probably not the cluster abstractions as is, since I require them for exchanging more than wireguard keys. For prototyping I have implemented what I believe is a much needed library for abstracting memberlist delegate patterns and providing simple usable event channels. I think it has become generic enough to serve as a basis for other projects.
My proposal would be:
Publish that library (branded sml, as in simpler memberlists), which is largely inspired by wesher cluster package
Make wesher packages a bit more ergonomic for using as a library
Move wesher on top of sml for easier integration in my current project
Move my own codebase on top of both wesher and sml.
I am exposing this plan for us to assess if it is worth the time and energy, or if I should just stick with a separate wireguard mesh implementation which is 80% copy pasted from wesher yet weighs a couple dozen lines of Go only.
Cheers 🤗
The text was updated successfully, but these errors were encountered:
Thanks for the suggestion! Very nice to hear wesher is still useful to you! 🥳
I have no problems with the idea on principle, but I haven't thought out the specifics, so I can't be really sure of the outcome. I'm also somewhat overextended with my OSS-time (as can be seen by the many open PRs left hanging 😞), so I'm not sure how much concrete help I would be.
Would this sml lib live inside the wesher project?
Hello,
I have contributed some features and refactoring to wesher in the past and have been using it for production clusters everyday since. Little to say I have come to love this project, its simple architecture and philosophy.
As a separate project I have been building a Kubernetes distribution, starting with duct-taped proof of concepts binding wesher and k3s together as independent processes. I have reached a point where binding the pieces together is better achieved in Golang directly, benefiting from the nice feats of Goroutine scheduler and memory manager.
In the end, I would very much like to embed wesher as a library for setting up the mesh vpn. I would use the wireguard abstractions and common types but probably not the cluster abstractions as is, since I require them for exchanging more than wireguard keys. For prototyping I have implemented what I believe is a much needed library for abstracting memberlist delegate patterns and providing simple usable event channels. I think it has become generic enough to serve as a basis for other projects.
My proposal would be:
sml
, as in simpler memberlists), which is largely inspired by wesher cluster packagesml
for easier integration in my current projectI am exposing this plan for us to assess if it is worth the time and energy, or if I should just stick with a separate wireguard mesh implementation which is 80% copy pasted from wesher yet weighs a couple dozen lines of Go only.
Cheers 🤗
The text was updated successfully, but these errors were encountered: