That’s a nice find. Thank you.
Looks like it would be beneficial to split the case when connection if explicitly marked as metered from the case when it’s a guess. I’ve put this down in a table.
Can we refresh?
-
xyes -
-no
(NetworkManager value)
| device | setting | NO | GUESS_NO | GUESS_YES | YES |
|---------+------------------------+----+----------+-----------+-----|
| classic | force | x | x | x | x |
| classic | hold | x | x | x | - |
| classic | hold-guessed | x | x | - | - |
| classic | default (hold-guessed) | x | x | - | - |
|---------+------------------------+----+----------+-----------+-----|
| core | force | x | x | x | x |
| core | hold | x | x | x | - |
| core | hold-guessed | x | x | - | - |
| core | default (hold) | x | x | x | - |
-
hold-guessed(strawman atm) could be the new value that we add, which indicates that the refreshes are held when connection is implicitly marked as metered -
holdis only effective when connection is explicitly marked as metered - classic systems default to
hold-guessed - core systems default to
hold
A hypothetical edge case, when a core system has a connection explicitly marked as metered with the intention of the setting being used by another application but would still like to receive snap updates would need to be updated to use refresh.metered=force.
1 Like
@mborzecki your proposal looks safe to me, but you would need to check the interfaces managed by systemd-networkd too. networkctl lists the type so you could apply similar heuristics to what NM does and then merge the value with the one from NM.
Not sure I entirely understand. We only look at NM, because AFAIK networkd has no support for reporting the connections as being metered or marking them as such.
Having NM report METERED_YES effectively means that the connection was explicitly marked as metered in NM (via nmcli or other means), thus the underlying interface must be managed by NM and the (current) default route goes though that connection. In other cases it will be METERED_{NO,GUESS_NO,GUESS_YES} which do not block refreshes.
@mborzecki see my previous comment about the network-manager snap not managing by default ethernet connections. What I am saying is that if you rely only on NM to decide if you can update snaps or not is buggy, as you could be in a case when the default route is via ethernet (managed by networkd) but NM reports GUESS_YES because it only manages a cellular connection (let’s say that this is for classic).
I see what you mean. I recreated this with with a wifi and eth. WiFi managed by NM with the connection marked as metered. Eth managed by systemd-networkd. When both were connected NM keeps reporting METERED_YES. Tweaking the metric of the route obtained via DHCP on eth connectio had no effect. Even if NM is looking at the main routing table it’s either not checking which route is effective or just ignoring routes through connections not managed by it.
At this point I’m thinking that maybe we should disable the feature or have the default allow refreshing just on Core devices. Thoughts?
On a side note, using vanilla config, the route via eth added by networkd had higher metric than the one over WiFi added by NM. Looks like this setup is broken out of the box with default settings.
IMHO I think the right course of action would be to check also interfaces managed by networkd, sort of replicating NM’s logic in snapd. NM actually does not do anything too clever here (wwan -> guess it is metered, otherwise is not), but for bluetooth interfaces which are not supported by networkd anyway. So doing a simple check by using networkd interface type and merging that with NM’s value is feasible. This would have the advantage of making the feature available also when NM is not present.
Hm, this should not happen if netplan is being used, see https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1639754 . I see metric 100 for eth in Ubuntu Core when the interface is managed by networkd.
I tested this on my Arch box without netplan so ended up using default values from networkd.
We’ll need to discuss that. I’m not particularly fond of poking both.
In which case will networkd have an ethernet connection while network-manager is active and managing a celular connection? If network-manager is active, wouldn’t the most likely route be for network-manager to also be in control of the ethernet connection?
For historical reasons related to console-conf, the NM snap does not manage by default eth connections.
Do we have a path forward then? If I understand the current status correctly, the option to default to holding on metered only on classic systems is still on the table.
We have discussed the topic once again during standup. There’s a feeling that more input from the field would be useful. Are you aware of any deployments using the setup when NM only handles WiFi and modem connections while networkd manages Ethernet links?
(cc @niemeyer)
That is the default if somebody installs the network-manager snap from the store, in, say, an RPi board with a UC image. For most of the commercial UC projects NM is set as the default for everything, but I cannot say this has happened in all cases.
For UC, I think you should not hold updates based on GUESS_YES shown by NM. It is too risky imho. For classic that could work, as for desktop NM manages everything by default. But, not sure what happens when somebody installs the network-manager deb package on a cloud image, though.
We need precise information here so we can take a decision. Who can go after the facts and make sure this is true?
We understand there are many theoretical scenarios in which one has several managers for several network connections and one of them may have a huge pipe that is not metered. We can’t possibly handle all such unknown cases.
The case of installing network-manager snap from the store, in an RPi2/3 board with a UC image would be one where this happens. Or in any other device, for what matters. It is something quite common when somebody needs some advanced set-up for wifi or needs support for modems.
1 Like
Any chance we could revisit the topic again and discuss the ways to go forward with this for the desktop users?
1 Like
Is this feature still requires opt-in?
could we re-visit this sometime?
2 Likes
As far as Ubuntu Core users are no affected by this change, I am fine with this.