Suggest to wait until the MetalLB controller pod is ready rather than using the --watch command

[emixam54]

What would you like to be documented:

I noticed that in the User Guide for installing MetalLB as a Load Balancer, it was suggested to use --watch to ensure that the pods were running. Instead I would like to see a suggestion to wait until the controller is ready.

Why is this needed:

To be consistent with the documentation for installing the NGINX Ingress (and it's probably more convenient than using --watch), I suggest to wait the same way until the controller is ready.

So I would add somthing like this to the Load Balancer documentation to wait for the controller to be ready:

kubectl wait --namespace metallb-system \
                --for=condition=ready pod \
                --selector=component=controller \
                --timeout=90s

Besides that, I can see that #2293 is somewhat similar, and even if the solution is not perfect, I can increase the timeout as noted in this issue, for both parts of the documentation (Ingress, Load Balancer and maybe elsewhere).

[BenTheElder]

That sounds about right to me.
We're hosting metallb docs for kind specific things but haven't had much bandwidth to work on them, pretty much all user contributed 😅

@fedepaol maybe you have thoughts

[fedepaol]

Sounds totally reasonable. I'd take the chance to bump the suggested version to 0.13.7 which contains this where we serve the readiness endpoint when the webhooks are ready and patched with the CA (meaning, you can start configuring MetalLB).

With the current version we have in Kind docs, MetalLB pods will be ready but there might be a slight delay before the webhooks get patched (we are using https://github.com/open-policy-agent/cert-controller which has more or less the same mechanism as cert-manager but embedded).

[emixam54]

MetalLB pods will be ready but there might be a slight delay before the webhooks get patched

I'm not sure I understand this, is it better to wait until after something other than the controller?

Also, I noticed that the speakers were ready after the controller. Maybe it would be better to wait for the speakers by doing --selector=component=speaker. What do you think?

[fedepaol]

MetalLB pods will be ready but there might be a slight delay before the webhooks get patched

I'm not sure I understand this, is it better to wait until after something other than the controller?

That doesn't change anything, just that with the new version the controller will be ready when the webhooks are ready to do validation (and will not fail, hopefully).

Also, I noticed that the speakers were ready after the controller. Maybe it would be better to wait for the speakers by doing --selector=component=speaker. What do you think?

I think we also have something like app=metallb that will catch both, I'd use that. If you want to choose one, the controller is the right one because it's the backend of the webhooks, so CR creation will fail until it's ready. The speakers might come later on, they will just start announcing the service when they come up (but it's not a big deal I guess).

[emixam54]

That doesn't change anything, just that with the new version the controller will be ready when the webhooks are ready to do validation (and will not fail, hopefully).

Okay, thank you :)

I think we also have something like app=metallb that will catch both, I'd use that.

Good idea!

[BenTheElder]

thanks for #2973 :-)

[emixam54]

thanks for #2973 :-)

Thank you all for the help and the review. This was my first contribution and I enjoyed the process :)