Monday, 1 August 2016

Re: Annoucing netplan -- Consolidated YAML network configuration across Ubuntu

Thanks for the feedback,
I'll file whishlist bugs as suggested to keep track and hope to find a day I can hide from everything else trying to create some experimental contribution to start things.

Minor remaining comments inline below:

On Mon, Aug 1, 2016 at 10:02 AM, Martin Pitt <> wrote:
Hello Christian,

Christian Ehrhardt [2016-08-01  8:18 +0200]:
> I read through the current yaml and recognized a lot from curtin/Maas that I
> knew. There is one point I wanted to ... well not discuss, but mention at
> least.

Please do discuss these. This is meant to be demand driven -- i. e. if
we need a feature for one of our installers, we add it.

> So in that s390x world and reading this announcement as written with a
> scope of: "unify and clean up networking configuration" I'd miss:
> - a way configure my Network card options (layer2, hwchksum, ..)

These settings are not currently exposed in NetworkManager or
networkd. You can configure a few layer 2 settings like wake-on-lan,
duplex, or MTU, but not the full range that you can set with e. g.
ethtool. However, netplan could certainly generate udev rules which
apply those settings via e. g. ethtool. udev rule generation already
happens for other purposes (mostly to blacklist a device from NM if it
is configured via networkd), so this isn't too hard in principle.

The hard part might be to avoid conflicts with the tools later on - in that case lszdev/chzdev.
Providing an ephemeral rule would be nice to be able to control things, but I'm afraid (and don't want to) of re-implementing chzdevs code.
How would it "take over" an ephemeral rule later on if the user changes configuration via chzdev - I have to think about that more.
Needless to say, contributions appreciated :-) (Just keep the test
coverage at 100%).

> - a way to identify my card by subchannel

I'm afraid I don't know what that means, this might be a z series
specific concept? This isn't exposed by networkd or NM directly, but
it might be possible that the subchannel is part of the ifnames
generated name so that you can use a name glob?

Think of it as a virtual pci-id (some people might want to hurt me now for this comparison) :-)
So yet it is currently rendered as part of the ifname subchannel c000 becomes encc000 and is usuable via that.
Just that people would likely want to say "c000" please get this config without caring in any way about device naming.
But I really think that is way down the priority list since encc000 is rather close.
> So it is a matter of our intended "target":
> - If we think of it as one place to configure all I need for my networking
>   config, but just above a certain level - I think it is ok.
> - If we think of it as one place to configure all I need for my networking
>   config - it is missing something.

I think the intention is the latter -- with emphasis on what we
actually need to configure in cloud-init, MaaS, subiquity, Ubiquity

> To be clear that is not a feature request in any way, I just want to
> ensure that this "separating line" between Network-Hardware and
> Network-Logical configuration is a conscious and intentional
> decision instead of happening accidentally.

It is not a conscious decision at all. I suggest filing wishlist bugs
against the nplan package or the netplan project to keep track of

Thanks for your suggestions!

Martin Pitt                        |
Ubuntu Developer (  | Debian Developer  (