cloud-init should parse initramfs rendered netplan if present

Bug #1861460 reported by Ryan Harper
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Fix Released
Critical
Canonical Server
cloud-init
In Progress
Wishlist
Ryan Harper
casper (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

initramfs-tools used to only execute klibc based networking with some
resolvconf hooks.

In recent releases, it has been greatly improved to use
isc-dhcp-client instead of klibc, support vlan= key (like in
dracut-network), bring up Z devices using chzdev, and generate netplan
yaml from all of the above.

Above improvements were driven in part by Oracle Cloud and in part by
Subiquity netbooting on Z.

Thus these days, instead of trying to reparse klibc files in
/run/net-*, cloud-init should simply import /run/netplan/$device.yaml
files as the ip=* provided networking information on the command line.
I do not currently see cloud-init doing that in e.g.
/cloudinit/net/cmdline.py

Revision history for this message
Ryan Harper (raharper) wrote :

On Wed, Jan 29, 2020 at 9:32 AM Dimitri John Ledkov <email address hidden> wrote:
>On Wed, Jan 29, 2020 at 3:17 PM Andreas Hasenack <email address hidden> wrote:
>
> cloud-init gets SRUed regularly as a new upstream version, i.e.:
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1~16.04.1 | xenial-proposed | source, all
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1~16.04.1 | xenial-updates  | source, all
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1~18.04.1 | bionic-proposed | source, all
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1~18.04.1 | bionic-updates  | source, all
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1~19.10.1 | eoan-proposed   | source, all
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1~19.10.1 | eoan-updates    | source, all
>  cloud-init | 19.4-33-gbb4131a2-0ubuntu1         | focal           | source, all
>
>
> Do these initramfs-tools improvements you speak of exist since xenial?
>
>
> Netplan rendering is available from xenial and up:
>
> ./initramfs-tools-0.122ubuntu8.16/scripts/functions:_render_netplan() {
> ./initramfs-tools-0.130ubuntu3.9/scripts/functions:_render_netplan() {
> ./initramfs-tools-0.131ubuntu19.2/scripts/functions:_render_netplan() {
> ./initramfs-tools-0.133ubuntu10/scripts/functions:_render_netplan() {
> ./initramfs-tools-0.133ubuntu12/scripts/functions:_render_netplan() {

Xenial images do not use netplan by default; however, cloud-init in Xenial
can read/parse it and render ifupdown as needed.

> Vlan support is available from eoan and up:
>
> ./initramfs-tools-0.133ubuntu10/init: vlan=*)
> ./initramfs-tools-0.133ubuntu12/init: vlan=*)
>
> If desired Vlan support can be backported.

Are the vlan values exported into rendered netplan?

> Note neither of above is available on Debian.

Generally, we can have cloud-init look for rendered netplan files, and prefer them over
the klibc files when present.

Changed in cloud-init:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Yes Vlan is defined in the runtime yaml, as native vlan.... With many keys set that cloud-init doesn't generate, for example the fact that that connection is a critical one and should not be torn down.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

$ cat /run/netplan/encc000.2653.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    encc000:
      match:
        macaddress: "96:89:5a:96:15:30"
      set-name: encc000
  vlans:
    encc000.2653:
      id: 2653
      link: encc000
      addresses:
        - "10.245.236.14/24"
      gateway4: "10.245.236.1"
      nameservers:
        addresses: ["10.245.236.1"]

$ sudo cat /proc/cmdline
ip=10.245.236.14::10.245.236.1:255.255.255.0:s1lp14:encc000.2653:none:10.245.236.1 vlan=encc000.2653:encc000 url=ftp://10.13.0.2:21/ubuntu-live-server-20.04/focal-live-server-s390x.iso --- quiet

Revision history for this message
Ryan Harper (raharper) wrote :
Changed in cloud-init:
assignee: nobody → Ryan Harper (raharper)
status: Triaged → In Progress
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: New → In Progress
Revision history for this message
Ryan Harper (raharper) wrote :
Frank Heimes (fheimes)
tags: added: installer s390x
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
assignee: nobody → Canonical Server Team (canonical-server)
importance: Undecided → Critical
tags: added: req4focal
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

maybe casper can hack this....

Revision history for this message
Joshua Powers (powersj) wrote :

Plan is to look at fixing this in Casper for Focal release. For post-focal release, we will work on a fix in cloud-init.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

This is awaiting cloud-init casper initramfs-tools livecd-rootfs pending changes all getting accepted and migrated to release pocket, and new image built using all of the above, before further tests/development can happen.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

casper has been changed to generate cloud.cfg instead of netplan, thus no further work in cloud-init is required for focal.

Closing this issue as fix released in casper & z project.

It would be nice for cloud-init to do what was originally asked, but that is a feature request of a lower priority now, that needs further spec / implementation as discussed on github PR.

Changed in cloud-init:
status: In Progress → Invalid
Changed in ubuntu-z-systems:
status: In Progress → Fix Released
Changed in casper (Ubuntu):
status: New → Fix Released
Revision history for this message
Dan Watkins (oddbloke) wrote :

Ryan has started work on this, moving to In Progress.

Changed in cloud-init:
status: Invalid → Triaged
status: Triaged → In Progress
Revision history for this message
Joshua Powers (powersj) wrote :

The portions required for focal are in and the remaining items are additional for cloud-init. Dropping req4focal tag.

tags: removed: req4focal
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers