The charm ships an alert rule (HostInterfaceMTUSize) which looks for changes in network interfaces. The rule does not filter out any interface, meaning that it will trigger for changes in br-int's MTU. More details about the br-int interface can be read on this issue's comment, but the bottom line is that its MTU is irrelevant. Users creating networks of different MTUs will cause the iface's MTU to change and this does not indicate any issue.
I can think only two ways of solving this, but more ideas are welcome of course.
Add a configuration property to the charm to specify a set of interfaces to be ignored by the rule.
Make the charm automatically detect which interfaces are relevant to monitor. This could be determined by reading the output of ip -j -d link and looking for a certain set of properties (like .linkinfo.info_kind == "openvswitch" and the like).
I see issues with both approaches, namely:
This is the path to growing the list of config properties for this charm to be potentially pretty long, as this is a very general charm ("monitor a host").
I'm not sure how often this could happen, but the list of interfaces to be ignored could change. This brings the need to detect that and re-render the rule.
Personally, I would go for alternative 1. Likely there are more interfaces we want to ignore, like TAP interfaces created for the VMs and so on.
Our immediate workaround is to add a very long silence matching device != "br-int", but this is far from ideal.
Enhancement Proposal
The charm ships an alert rule (
HostInterfaceMTUSize) which looks for changes in network interfaces. The rule does not filter out any interface, meaning that it will trigger for changes inbr-int's MTU. More details about thebr-intinterface can be read on this issue's comment, but the bottom line is that its MTU is irrelevant. Users creating networks of different MTUs will cause the iface's MTU to change and this does not indicate any issue.I can think only two ways of solving this, but more ideas are welcome of course.
ip -j -d linkand looking for a certain set of properties (like.linkinfo.info_kind == "openvswitch"and the like).I see issues with both approaches, namely:
Personally, I would go for alternative 1. Likely there are more interfaces we want to ignore, like TAP interfaces created for the VMs and so on.
Our immediate workaround is to add a very long silence matching
device != "br-int", but this is far from ideal.