Edge-Node-Cluster: node, pod, volume, replica, upgrade health.

[andrewd-zededa]

Edge Node Clusters: nodes, volumes, replicas, upgrades

Node Info: role, age, ip
Pod Info: status, restarts, ip
Volume and Replica Info: rebuild progress, health
Upgrade Status: cluster wide and node components

[andrewd-zededa]

Noticed a bad option in proto/info/edge_node_cluster.proto, fixing that in the next push.

[milan-zededa]

Yetus has some opinions on the naiming of enum values...

[andrewd-zededa]

@milan-zededa I don't see a 'make yetus' rule like the eve repo has, is there another convenience method to kick it off locally with the rules for this repo?

[andrewd-zededa]

Addressed the type concerns for relative -> absolute times now using google.protobuf.Timestamp. I think I'll push another change to rename the 'age' fields to 'creation_timestamp' to match field name in Kubernetes json output.

[andrewd-zededa]

Latest commit renames 'age' fields to absolute style 'creation_timestamp'

[andrewd-zededa]

Latest commits had to pull ErrorInfo out to a separate file to resolve dependency issues created when adding KubeClusterInfo to InfoContent.

[eriknordmark]

Looks like there are still build issues

[andrewd-zededa]

Addressed some yetus issues I missed, and separate commit for the generated go, python, svg files.

[andrewd-zededa]

Reorganized and moved back ErrorInfo due to the yetus issues. I have a yetus target in my local copy of the makefile which I've been experimenting with using to try to catch these issues before a PR but it seems its not catching enough yet.

[eriknordmark]

LGTM

[andrewd-zededa]

The publishing process of the top level message KubeClusterUpgradeStatus can be simplified if it is allowed to be a top level message type to be published. Only one node will be upgrading/updating at any time so no leader election should be needed to publish KubeClusterUpgradeStatus if the currently updating node is the only node which publishes it. The message would only be sent while the edge-node reports that it is in upgrade-test.

@naiming-zededa What do you think?

[naiming-zededa]

@andrewd-zededa makes sense, since the nodes are upgrade one at a time and it needs to have controller connection at the time, so update by it's own is fine.

[andrewd-zededa]

Latest change elevates KubeClusterUpgradeStatus into the InfoContent field of ZInfoMsg.

[andrewd-zededa]

I'll fix a mismatch I see between 'upgrade' / 'update' conventions, I'll fix those.

[eriknordmark]

@andrewd-zededa looks like you got a conflict with Pramodh's PR.
Are there some remaining issues causing yetus failures?

[andrewd-zededa]

Yeah I'll fix the conflict, looks like I just need to regenerate the built files

[andrewd-zededa]

Updated comments on KubePodStatus, rename upgrade->update to match existing baseos update. Rebase on main and rebuilt generated files to resolve conflict.

[andrewd-zededa]

Looks like the two info messages KubeClusterInfo and KubeClusterUpdateStatus should probably be renamed to ZInfoKubeClusterInfo and ZInfoKubeClusterUpdateStatus but these types are getting a bit long so I'm open to suggestions to shorten them.

[andrewd-zededa]

Another commit pending to append to the ZInfoTypes enum.