The reason should shed light on why DNS is unavailable.
The message should also shed light, and in this case the message is "No DNS DaemonSets available". The dashboard isn't showing the most useful detail for this and many other cases. What reason string would you consider to be a fix?
Messages don't go back to telemeter unfortunately. NoDaemonSetsAvailable would be an improvement. Or NoDNSPodsAvailable? Those things would at least make it a bit clearer where the problem is. If there's something even more specific (why are no daemonsets available? were they created and didn't get scheduled? did they not get created? are they invalid for some reason? Was the operator unable to create the daemonset? If pods were created and not scheduled, can we tell why?) that can be reported, even better.
I like NoDaemonSetsAvailable — it's probably the most accurate thing we can say right now. I like the idea of doing a deeper "why" analysis to surface. There are lots of opportunities for improvement here and in the ingress operator (which has received the most of these improvements lately). For now, I'd like to resolve this bug with the improved reason, as I don't anticipate having time to do anything more sophisticated for the release.
> For now, I'd like to resolve this bug with the improved reason i think that's a fine start. It gives us a good starting point for questions to start asking about the cluster.
I think https://github.com/openshift/cluster-dns-operator/pull/134 was a decent fix for this issue. In addition to fixing the status flapping, we improved the status messaging in the ways discussed here.
verified as https://bugzilla.redhat.com/show_bug.cgi?id=1761506#c2
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0062