Annoucing netplan -- Consolidated YAML network configuration across Ubuntu

Christian Ehrhardt christian.ehrhardt at canonical.com
Mon Aug 1 09:50:21 UTC 2016


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 <martin.pitt at ubuntu.com> 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
> etc.
>
> > 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
> these.
>
> Thanks for your suggestions!
>
> Martin
> --
> Martin Pitt                        | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160801/95e94096/attachment.html>


More information about the ubuntu-devel mailing list