MDC: inconsistent handling of absence of namespace

[metacosm]

When a resource info is added to MDC, it is done in several inconsistent ways with respect to how the namespace, or rather the absence thereof, is handled:

• addResourceInfo does not add the namespace key if the namespace is null
• addResourceIDInfo adds the key but sets the value to no namespace
• addInformerEventInfo adds the key and sets the value to null (which causes an NPE in at least some MDC implementations)

This should be unified.

[metacosm]

#3185 addresses part of the issue but the discrepancy remains between how resource and resource id are handled…

[csviri]

Good question if we should set there "no namespace" or we should not add the key, I would sat rather some value that is a placehorder for Cluster Scoped

[metacosm]

Note that this discrepancy (along with the NPE issues) was introduced by the recent MDC changes and didn't get picked up by reviews… :(

[metacosm]

Good question if we should set there "no namespace" or we should not add the key, I would sat rather some value that is a placehorder for Cluster Scoped

I don't really have an opinion here. It's generally understood when working with kubernetes that resources without namespaces are clustered. That said, we might want to highlight a missing namespace anyway in case this is an issue in the user code, in which case providing a default value would be better than omitting the key?

[csviri]

That said, we might want to highlight a missing namespace anyway in case this is an issue in the user code, in which case providing a default value would be better than omitting the key?

Also what I was thinking about if somebody is collecting logs to Splunk or ELK, maybe it is easier to do queries for cluster scoped resources when there is such value, than for the case when there is sometimes key other times not.

[metacosm]

That said, we might want to highlight a missing namespace anyway in case this is an issue in the user code, in which case providing a default value would be better than omitting the key?

Also what I was thinking about if somebody is collecting logs to Splunk or ELK, maybe it is easier to do queries for cluster scoped resources when there is such value, than for the case when there is sometimes key other times not.

This would be a break of the current logging, though, since, so far, the key was omitted.

[csviri]

I see, ok IMO let's emit it consitently, and in case somebody coplains we can adjust.