Bug 896572

Summary: [rfe] systemd targets indicating the level of network service
Product: [Fedora] Fedora Reporter: Ales Kozumplik <akozumpl>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dcbw, jzeleny, pahan, samuel-rhbugs, tadej.j, thaller
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-13 16:17:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ales Kozumplik 2013-01-17 14:54:10 UTC
This follows the discussion in bug 879370. There are regularly undertaken actions on a system (fired e.g by a cron job or a systemd timer) that use network. If they are overall low priority (noncritical backups, yum metadata synchronization) we only want them to run if we're on a cheap network connection. Currently there is no way for services like this to tell. Here's what I image should happen in NetworkManager to remedy this:

1) add a network option specified by the user where he can express if the particular connection is cheap or expensive
2) if cheap connection is activated, enable network-cheap.target systemd unit. If no connection or only an expensive connection is activated, have this unit disabled.
3) Have some reasonable defaults, e.g. a wired connection is cheap by default, everything else is expensive.

Comment 1 Ales Kozumplik 2013-02-07 09:19:52 UTC
Same bug in the gnome bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=688216

Comment 3 Fedora Admin XMLRPC Client 2015-08-18 14:56:49 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Thomas Haller 2016-09-13 16:17:48 UTC
I closed upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=688216#c5 as fixed by upstream release 1.2.0.


As I read comment 0, points 1) and 3) are satisfied.


Thus, it's fixed on Fedora 24, which ships NM >= 1.2.0





I am not convinced about starting a NetworkManager specific systemd-target (point 3)). If the user already buys into NetworkManager, maybe he can just monitor the D-Bus API of NetworkManager for the "Metered" property.

On the other hand, it might be great to have a official systemd target for that (like the special targets network.target and network-online.target). Than it wouldn't be a NetworkManager-only thing.
However, in face of multiple network-management-daemons, it's not clear who is responsible for starting/stopping this target and how multiple such daemons cooperate.

Yes, definitely an interesting idea... but seems too much for this downstream bug and needs more discussion. Maybe better suited for the mailing list networkmanager-list or upstream https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager . Maybe it would be best if this becomes an official systemd-target, so maybe that would be best as an RFE for systemd and discuss the semantic of this there.