Merge ~morphis/netplan/+git/netplan:nm-snap-support into netplan:master
| Status: | Rejected |
|---|---|
| Rejected by: | Martin Pitt on 2016-09-27 |
| Proposed branch: | ~morphis/netplan/+git/netplan:nm-snap-support |
| Merge into: | netplan:master |
| Diff against target: |
82 lines (+35/-4) 1 file modified
src/netplan (+35/-4) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Martin Pitt | 2016-09-23 | Disapprove on 2016-09-26 | |
|
Review via email:
|
|||
Description of the Change
Add support for the network-manager snap
If the network-manager snap is installed we should restart its service unit rather than the one of the debian package to get it to read its configuration files again.
| Simon Fels (morphis) wrote : | # |
The naming of the service file unit or the Alias is nothing we can control from the snap itself as the service unit is created from snapd which creates a unique name for it to avoid clashes between multiple snaps. Created https:/
For the short term we need to go with such a patch as I can't say if this will be accepted as a feature for snapd or not.
| Simon Fels (morphis) wrote : | # |
Reworked things a bit as we need to use the nmcli binary from the snap too. With that it makes things even harder to just abstract the snap use through an Alias= line in the systemd service unit as we also need to use the right nmcli binary which is "network-
| Martin Pitt (pitti) wrote : | # |
I'm sorry, but this is just broken. That binary name is being used way more widely than the .service name. If you want to credibly provide an OS component as a snap, then this also must provide the expected API, CLI, etc. to the user. Note that it already is not possible to install this on touch, or a "personal" snappy device etc. which has network-manager.deb installed. I. e. it's going to clash anyway, so you can as well provide the proper executable names.
| Simon Fels (morphis) wrote : | # |
@Martin: Sure, and we would do if snapd would allow this :-)
| Martin Pitt (pitti) wrote : | # |
Right, but then we need to teach snapd about it -- we have the source :-)
Anyway, as discussed on IRC I will add it to the xenial backport to unblock this -- but this again now puts *me* in the position of having to get rid of it instead of the actually responsible people.
| Martin Pitt (pitti) wrote : | # |
There's a bug and a style issue, comments inline.
| Simon Fels (morphis) wrote : | # |
Sure, we have the source but given all the existing work for GA and the commercial projects we have ongoing and need to finish in time we need to do this somewhere rather than not doing it which would put things at risk.
I agree this needs to be fixed in a better way. There will be AFAIK a session on the UES sprint to discuss providing commands like nmcli to the system from snaps. That would be one thing we need to solve for this.
| Simon Fels (morphis) wrote : | # |
Fixed review comments.
| Martin Pitt (pitti) wrote : | # |
Two more issues (one even leads to FTBFS), I'll fix them when applying this to the xenial backport. See bug 1627641.
Unmerged commits
- 9878fa0... by Simon Fels on 2016-09-23

Having a different name for the well-known NetworkManager. service is ugly IMHO -- you are going to need to sprinkle this alternative name into every piece of software that tries to talk to it. And you can't possibly co-install it with the .deb as they would clash on D-Bus names.
So I'd really prefer to avoid patches like this, as they are super-ugly. I acknowledge that snapd presumably wants a canonical name like "snap.something", but the unit could just have "Alias= NetworkManager. service" to make it compatible with the deb.
I also have some inline comments, but they are hopefully moot with the Alias.