EtcdIsVoter status condition viewed as an error.

[reefland]

I know #8033 added this condition to K3s, and that issue had comments about using an annotation vs a new status condition. But it seems that the new status condition is considered an error/issue by other applications.

Examples

• Longhorn issue [BUG] Warning events are being spammed by Longhorn - CRD longhorn/longhorn#7290 it was suggest that longhorn needed to change to adjust.
• CMK issue https://forum.checkmk.com/t/kubernetes-node-condition-etcdisvoter/46471

My question, is do the other apps really have this wrong?

When I use Kubernetes LENS, it's a warning:

If I use k8sgpt its an error condition:

0: Node k3s03()
- Error: k3s03 has condition of type EtcdIsVoter, reason MemberNotLearner: Node is a voting member of the etcd cluster

1: Node k3s01()
- Error: k3s01 has condition of type EtcdIsVoter, reason MemberNotLearner: Node is a voting member of the etcd cluster

2: Node k3s02()
- Error: k3s02 has condition of type EtcdIsVoter, reason MemberNotLearner: Node is a voting member of the etcd cluster

These are just a few tools I use, its probably likely that other tools report this issue as well.

I guess the k3s community has to open issues with other projects and try to explain / convince them the issue is with how they handle/report conditions to clean things up?

What if instead of K3s using a condition status of True (which I assume causes the confusion?) EtcdIsVoter: True if it was EtcdIsLearner: False would that reduce the noise from other applications? (or was using an annotation a better option?)

[brandond]

There is no "right" way to do conditions, they are implementation specific by design. Anything that treats an unknown condition is an error when the status is true is making an unchecked assumption. See the discussion at longhorn/longhorn#7290 (comment)

Some conditions are errors and status: True is bad, for others like “Ready”, status: True is good.