Port forwarding error immediately after installing the GitOps Dashboard not on the same run when installing Flux

[opudrovs]

Closes #2489

It looks like the bug was caused by a big "typo": when moving the "wait for dashboard ready"code to a separate file, I copied only the wait for reconciliation code, twice. 🤦

So, I've added code to wait for the dashboard reconciliation and pod running properly. It is working as expected now.

Questions:

1. Is it OK to use the pod and wait for its status == running to wait for dashboard ready?

I also have some old code which seems to work for our purpose, but it uses a HelmRelease:

// wait for dashboard to be ready
if err := wait.Poll(interval, timeout, func() (bool, error) {
	dashboard := &helmv2.HelmRelease{}
	if err := kubeClient.Get(context.Background(), types.NamespacedName{
		Namespace: namespace,
		Name:      helmReleaseName,
	}, dashboard); err != nil {
		return false, err
	}

	return apimeta.IsStatusConditionPresentAndEqual(dashboard.Status.Conditions, meta.ReadyCondition, metav1.ConditionTrue), nil
}); err != nil {
	return err
}

But I think it's better to use the pod instead of the HelmRelease, correct?

2. Is it OK to add getting the pod the way I did with GetPodFromSpecMap? Because I don't actually need the whole specmap.

3. Also added getting any type of pods, including non-running pods with GetPodFromSpecMap.

@chanwit, @ozamosi are you OK with that or do you know of a better way? Would it be better to wait for the deployment object ready instead? If yes, how can I get it?

4. I tried just directly getting the pod with kubeClient by name, but its name looks like that ww-gitops-weave-gitops-96b7c495f-vsp8c and names without this suffix do not work.

So, if you know how to get the pod directly with kubeClient based on the name without the suffix, I would not need to use GetPodFromSpecMap.

[chanwit]

Thank you @opudrovs!

Pods created by a deployment usually have suffixes.
The best way, which was already implemented in GetPodFromSpecMap, to obtain pods was to retrieve them via the app's labels. If GetPodFromSpecMap worked for you, I think it's ok.

[opudrovs]

@chanwit ok, thank you! I will check if I can simplify the code and retrieve the pod directly with the app labels.

[ozamosi]

This doesn't mean the pod is running, just that it's entered the phase running. Which is to say, it might be in a crash loop. To know that the pod is actually happy and ready to use, you'd need to check the condition.

I found this page https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle and it's explanation of phase vs conditions helpful.

[opudrovs]

Thank you, very helpful! I will add checking for conditions in the followup PR.