Library flexibility use case

[chuckha]

What would you like to be added:
I have a use case (kind as a cluster-api provider) where I'd like to be able to provision a single control-plane cluster with a load balancer. This gives me the flexibility of adding additional control planes at a later time.

Why is this needed:
The general workflow looks like this:

• Setup load balancer
• Set up control plane
• Optionally set up workers and/or more control planes.

The internals make this somewhat difficult since it's not possible to define the external loadbalancer in a cluster configuration. Even if using the library, CreateExternalLoadBalancerNode still requires the setup action which is inside the internal package. The only way to do it using kind is to create two control planes then delete the second one, but that is questionable from an etcd perspective since I think that would mean it would no longer have quorum.

Overall, I'd like there to be more flexibility with the library. I'd like to be able to use the actions inside internal as part of the library.

[BenTheElder]

hmmm

Related: the entire HA load balancer thing is broken and needs rework :( #588

That said the loadbalancer it is meant to be an implementation detail of "HA", which is why it's not a node type in the config.

kind in general does not currently natively support modifying the cluster after provisioning in general as a complexity tradeoff. The general contract is "create a cluster that looks like this" (or delete) and it does. "kinder" covers experiments outside of that scope.

Overall, I'd like there to be more flexibility with the library. I'd like to be able to use the actions inside internal as part of the library.

Current stance on that is to use kinder, the set of actions kind performs and what exactly they do is definitely still in flux. They were moved into internal to signal the intention not to make them an API surface for the immediate future because they're unstable implementation details.

[chuckha]

Sounds good, appreciate the response! I'll close :) thank you!

[BenTheElder]

Appreciate the understanding 😅

We are still tracking #324 which covers a lot of this request FWIW, at some point when things stabilize we should reconsider what is kind and what is kinder 😂

[fabriziopandini]

@BenTheElder @chuckha this point was raised also when discussing v1alpha3 config proposal in #340 (comment)

I'm happy to help in making this happen; it will be really helpful to make accessible also the logic for creating/updating the LB Config that already exists in kind

[chuckha]

It sounds like that proposal is out of scope for the kind project.

I think there is room for a library built around kind providing the features we want without burdening this project with the additional use cases.