Closed MegaShinySnivy closed 1 year ago
Discussion supporting another use case for making it optional https://github.com/techno-tim/k3s-ansible/discussions/174
Also, if we are to do this we would also need to expand our tests to include this.
That should be pretty simple, use the existing test and skip the metalLB test section when testing this functionality, or optionally use the existing metalLB test and invert the pass condition.
I have create PR #191 which splits into individual task that are included on run time for add-on such kube-vip, metallb and so on. We could expend on this and add flag to skip those steps if it get merge back to master. Going with a modular approach could be useful given we all have unique homelab and needs.
Ooh, I quite like that approach. Leaving it up to the user to decide which parts are required.
I will amend my PR later next week to check if the service_version_tag is defined and have ansible include those task when variable exist.
So if you want to skip metallb install, you could just change the tag to be empty. I haven't done any of this work but that how I figured out it could be the easiest to implement. Obviously I will need to document this.
Also, something I notice is that this playbook still uses a configmap to manage MetalLB, something that isn't supported as of Version 0.13.2. Should I make another issue to address that?
Should I make another issue to address that?
I would suggest you could make a Pull Request to propose those changes you want to include. If you know what needs to change and include metallb doc related to those changes in the configuration it should be easy to review and get accepted.
If you have never made a PR, there are plenty of good tutorials online but given the details of your suggestion I think you should be fine.
That's the issue, I don't know what needs to be changed, only that you have to use CRDs and that ConfigMaps are dead. Someone far smarter than I will have to make that PR :sweat_smile:
to use CRDs and that ConfigMaps are dead
I looked into the Backward Compatibility and could figure out what is wrong in the current way of doing things ? Can you elaborate a bit more ?
Ah. You see, I made one of the classic blunders, and got my projects confused. Please ignore my comment on configmaps!
Some people (read: I) would like to install and manage MetalLB separately from this playbook, that way I can do things like install MetalLB in BGP mode. While I can delete the MetalLB and install it from Helm afterward, it would be nice to skip the original install so it doesn't leave extra noise behind. Having an option in the all.yml, maybe something where if you leave the MetalLB IP range blank it skips the install entirely, would be nice.