We have above variable only for worker nodes. We should add that to the controllers as well.
If that is already available on controllers, then please document such in https://github.com/kinvolk/lokomotive/blob/master/docs/configuration-reference/platforms/packet.md.
I think we may want to treat this issue in a generic way: rather than saying "enable/disable BGP" on Packet clusters only, we may want to have a platform-independent knob at the worker pool level which designates the pool as a pool of ingress nodes. We could call such a knob lb_enabled for example.
Setting this knob to true would control a platform-specific implementation. See https://github.com/kinvolk/lokomotive/issues/372 for more info.
Regardless the above, I think we should consider making this knob opt in rather than opt out with a default of false. For example, even if we leave the knob as Packet specific, we can name it enable_bgp and set the default to false. The rationale:
true value in our config samples.BTW, maybe we should disable the BGP on controller nodes always? What would be the scenario to use BGP on controller nodes?
A scenario would be e.g. routing traffic to a pod running on a controller node via MetalLB. I'm not aware of actual use cases which need this. I think we should disable BGP on controller nodes, i.e. not even expose an option to enable it.
Most helpful comment
I think we may want to treat this issue in a generic way: rather than saying "enable/disable BGP" on Packet clusters only, we may want to have a platform-independent knob at the worker pool level which designates the pool as a pool of ingress nodes. We could call such a knob
lb_enabledfor example.Setting this knob to
truewould control a platform-specific implementation. See https://github.com/kinvolk/lokomotive/issues/372 for more info.Regardless the above, I think we should consider making this knob opt in rather than opt out with a default of
false. For example, even if we leave the knob as Packet specific, we can name itenable_bgpand set the default tofalse. The rationale:truevalue in our config samples.