Replies: 3 comments 11 replies
-
Thanks for writing this out, here's my take on this:
All of those have their usecases, all should be supported. Now...
IMO Longhorn configuration shouldn't be half of this projects code, it wasn't designed to be configured via Terraform and I don't think we should force it to be that way. Most of the features you described would, at least for me, fall into a category of a "Longhorn Kubernetes Operator" or to be integrated into Longhorn itself. As another solution, it might be more practical and easier to use something like Ansible to achieve the manual work you were describing. In conclusion, it will be fine to implement outputs for nodes so that other modules can use them as well as better labeling system for the nodes, but the complex logic around Longhorn should be kept separate from this repository. Terraform wasn't made to achieve half automatic half manual work, it's supposed to do infrastructure as code declaratively and predictably saving everything to a state file. Since I'm just a contributor to this project, don't take my word as something that is 100% right. I would gladly have @kube-hetzner/core comment on this as well. |
Beta Was this translation helpful? Give feedback.
-
The last time I tried, I did not find a pure tf solution for annotating the nodes with through k3s configuration. I currently label them, and then after kube-hetzner completed, I run a local bash kubectl command to annotate certain nodes of they have a certain label. Pretty disappointing. I would cheer if you find a better way!
…-------- Oorspronkelijk bericht --------
Op 22 feb. 2024 16:51, schreef K. N. :
***@***.***(https://github.com/andi0b) That's what I was going to say, you beat me to it, the best way to convey your vision for improvements is through a PR :)
—
Reply to this email directly, [view it on GitHub](#1196 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3W7X2MLKHFPKUV42AI7BYLYU5SOTAVCNFSM6AAAAABCOILDXSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKNJYGYZDG).
You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
That's a good point. It's really time for a full blown docusaurus website for this project. But that takes a lot of added maintenance, nothing is worse than faulty outdated documentation.
…-------- Oorspronkelijk bericht --------
Op 22 feb. 2024 18:11, schreef andi0b :
> Then you can design your longhorn volumes on top of these (mirroring, distribution, etc.). This is very requirements-specific, therefore adding the configuration via annotations, CRDs, etc afterward makes quite a sense...
Exactly. After the cluster, nodes and networking is created it's just like any other Kubernetes cluster. And the whole Terraform ecosystem can be used to customize it.
I think even some currently built in features could be removed and just replaced by documentation and code samples (Longhorn, Nginx, ...)
—
Reply to this email directly, [view it on GitHub](#1196 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/A3W7X2NY4UIYS6KURAC7I53YU535PAVCNFSM6AAAAABCOILDXSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKNJZGU4DG).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
This project has support for Longhorn and also mounting a Hetzner Cloud Volume to /var/lib/longhorn as it's default disk. I think this feature is not really great how it is right now (see #1194 and #1195) , I wanted to share some ideas I've collected over the past few days.
Maybe I'm going to submit a PR for those changes if I manage to do it.
Why use Longhorn on Cloud Volumes in the first place?
Possible providers for Persistent Volumes (PVs) are:
Longhorn has quite some benefits over the other solutions. It's easily possible to snapshot/backup volumes, move them between nodes and pods without longer interruptions.
Also a hybrid scenario is possible, to move/sync longhorn volumes to other cloud providers and even on premise. Although performance implications are expected if the network is not fast enough (non fiber).
What's missing now
The possibility to add more than one disk to Longhorn, for example I would like to do:
What I think should be added to this project
Extend node pools with volume support:
Maybe even auto-configuration for multi-disk Longhorn
node.longhorn.io/default-disks-config
to nodes in the pool, to make longhorn pick up the volumesAlternative ideas:
terraform-hcloud-kube-hetzner
moduleBeta Was this translation helpful? Give feedback.
All reactions