k3s component actually waits for node to come up

[YrrepNoj]

The previous command was just running the 'k get nodes' command without verifying any nodes were actually returned.

Description

As part of the 'after' script definitions for the k3s component we will now verify that at least 1 k3s node is returned when 'kubectl get nodes' is executed.

Type of change

• Bug fix (non-breaking change which fixes an issue)

[YrrepNoj]

I was originally doing a k ... -o json and then using jq to parse the items list to make sure the list had more than one item but since 'jq' isn't default on some OS's I ended up doing more simple grep.

[RothAndrew]

I think the reason that kubectl get nodes works as is is that it returns a non-zero exit code if it can't connect to the cluster. We don't actually care how many nodes there are, just that we are making a good connection to the cluster.

[jeff-mccoy]

I think we may need to confirm wc/ Grep actually exist on our target OS's as well--or do it in code and get rid of this step. I actually think something that blocks everything in code until there is a complete node is cleaner than this anyway. Thoughts?

[RothAndrew]

Maybe something like this?

components:
  - name: k3s
    needsK8s: false
    ...

  - name: InstallSomeFile
    needsK8s: false
    ...

  - name: someFooBarK8sDeployment
    needsK8s: true
    ...

[YrrepNoj]

I think the reason that kubectl get nodes works as is is that it returns a non-zero exit code if it can't connect to the cluster. We don't actually care how many nodes there are, just that we are making a good connection to the cluster.

It will not return an error code if the nodes are not up yet, which is a race condition we ran into when trying to get the node architecture when initializing with k3s. We care that at least 1 node is there.

[RothAndrew]

That makes sense.

If this very small change fixes that than I'm all for it. Something bigger that resolves the issue in a more elegant way can come later

[jeff-mccoy]

Maybe something like this?

components:

  - name: k3s

    needsK8s: false

    ...



  - name: InstallSomeFile

    needsK8s: false

    ...



  - name: someFooBarK8sDeployment

    needsK8s: true

    ...

You don't even need that. The only time we don't need k8s is when you are only moving files and that is already accounted for in the package deploy stage. We already know if you need k8s. I think rather than using scripts (which was a band-aid and brittle) we should just either add something to the k8s getstate function or some call before that to make sure we have a real/valid k8s connection to a running cluster.

[YrrepNoj]

I'll replace this PR with something like that then :)

[jeff-mccoy]

@YrrepNoj I believe you're going to rewrite this to use something in go instead

[YrrepNoj]

@jeff-mccoy I think this should be more in line with what you were thinking

[jeff-mccoy]

I think there's still some issue with the test--but this is good enough to merge and finish cleaning in the main branch now. Thanks!