write.wrestle.town

Reader

Read the latest posts from write.wrestle.town.

from OddBloke's Blog

I keep notes of the work that I do as a member of Canonical's Ubuntu Server team. This post is a breakdown of the highlights of what I spent my last week doing.

cloud-init

  • Landed MP 372491 to give us additional debugging for an ongoing bug investigation

curtin

  • No substantial curtin work this week

ubuntu-advantage-client

  • Code reviews (all for Chad Smith):
    • Reviewed and landed #733
    • Reviewed and landed #738
    • Reviewed #742

Miscellaneous

  • Rotating Monday triage for me this week, plus regular triage on Tuesday
  • Visiting family in the UK before our sprint the following week, so less work days than usual (plus packing for sprint etc.)
  • Submitted #1034 to multipass, requesting some functionality that would make testing cloud-init using multipass much easier
 
Read more...

from OddBloke's Blog

I keep notes of the work that I do as a member of Canonical's Ubuntu Server team. This post is a breakdown of the highlights of what I spent my last week doing.

cloud-init

  • Validation of the SRU (Stable Release Update) of cloud-init back into xenial, bionic and disco
    • Performed manual boot verification on Oracle Cloud Infrastructure
      • This resulted in the discovery of a minor regression on Oracle, bug 1842752
      • This bug is cosmetic, and causes boot to slow down by <0.1s
      • Under normal circumstances, we would address even this, but Ubuntu images in Oracle Cloud Infrastructure will be migrating to the Oracle data source in the near future, so the impact of this will be substantially limited
    • Wrote the verification script and bug content for bug 1812857
      • This took the best part of a day because I ran into a number of roadblocks; I don't have an OpenStack I can modify network config on, performing validation in a VM would require crafting OpenStack network_data.json for the issue, and bond setup inside xenial containers wasn't working for me
      • Excerpt from my notes:
        • Figured I could probably do better in a VM with a ConfigDrive attached
          • I couldn't
  • Code review

curtin

  • No substantial curtin work this week

ubuntu-advantage-client

  • No substantial UA client work this week

Miscellaneous

  • Back after a week and a day off, so spent the early part of the week just catching up on email etc.
    • Footage of me destroying my email backlog: Footage of me destroying my email backlog
    • (I was at this show during my time off!)
  • Submitted several talk proposals for PyCon Canada 2019, fingers crossed!
 
Read more...

from OddBloke's Blog

I keep notes of the work that I do as a member of Canonical's Ubuntu Server team. This post is a breakdown of the highlights of what I spent my last week doing.

cloud-init

  • Landed MP 371461, a minor doc improvement
  • Landed MP 371403, which allows secondary VNICs in Oracle Cloud Infrastructure to be configured by cloud-init!
    • This only works on Virtual Machines (not Bare Metal Machines)
    • At the moment, this requires configuration in your image/instance to enable
  • Substantial internal discussions about the future of initramfs network configuration in cloud-init
    • To summarise: nothing needs to change, but we would like to drop the “initramfs” NetworkConfigSource and merge its behaviour into the “fallback” NetworkConfigSource
    • (On an iSCSI-root system, for example, the last-resort, fallback network config should be what the initramfs wrote out, not DHCP-on-first-interface.)
  • Completed my inital dig into Dracut network configuration (my notes are here)
  • Landed MP 371673 with the initial refactoring required to introduce Dracut network configuration parsing
    • This doesn't change any behaviour, it just moves klibc from being the source of initramfs network configuration to being a source of initramfs network configuration (albeit the only source, for now)
  • Revisited bug 1834875 to confirm that this issue doesn't lie within cloud-init
  • Code review
  • Landed MP 371350 (see last week for details)
  • Submitted MP 371683 with minor .gitignore updates

curtin

  • Dropped building of Python 2 Ubuntu package (python-curtin) in a new upload (19.2-6-g88a1a7ec-0ubuntu1
    • Thanks once again to Ryan Harper for sponsoring the upload
    • This required a minor change upstream (MP 371589) so that the Python 3 tests could be run without the Python 2 tests

ubuntu-advantage-client

  • No substantial UA client work this week

Miscellaneous

  • Uploaded a new upstream snapshot of simplestreams to eoan (0.1.0-25-gba75825b-0ubuntu1)
    • Thanks to Robie Basak for the sponsorship!
  • Spent some time looking at dropping Python 2 from the simplestreams Ubuntu packaging
    • I have branches for this locally, but we have downstream consumers that depend on the Python 2 packages still, so we'll do it next cycle
  • Investigated and filed a Launchpad bug that was causing our CI and autolander triggers to fail
  • On vacation next week, so won't be back to work until after International Worker's Day (North American Edition)
 
Read more...

from OddBloke's Blog

Note: This blog post is essentially notes from some investigation into dracut in the context of supporting its network configuration in cloud-init. Its intended audience is other cloud-init developers. If you're looking for an accessible introduction to dracut, this isn't it, I'm afraid!

I'm currently trying to work out how we should proceed with the parsing of dracut network configuration, to have feature parity with Ubuntu/initramfs-tools. This blog post is partly reporting on what I've found, and partly starting a discussion around how we should proceed.

Background

All of this was run on an Oracle Linux 7.6 Virtual Machine running in Oracle Cloud Infrastructure. The version of dracut:

$ yum list installed | grep dracut.x
dracut.x86_64             033-554.0.3.el7        @anaconda/7.6  

Findings

This is what dracut produces in /run/initramfs:

$ tree /run/initramfs/
/run/initramfs/
├── log
├── net.00:00:17:02:3f:34.did-setup
├── net.00:00:17:02:3f:34.up
├── net.ens3.dhcpopts
├── net.ens3.did-setup
├── net.ens3.gw
├── net.ens3.lease
├── net.ens3.pid
├── net.ens3.resolv.conf
├── net.ens3.up
├── net.ifaces
├── rwtab
└── state
    ├── etc
    │   ├── resolv.conf
    │   └── sysconfig
    │       └── network-scripts
    │           └── ifcfg-ens3
    └── var
        └── lib
            └── dhclient
                └── dhclient-b560099e-e294-4563-bc2f-fe800312c96b-ens3.lease

Note that 00:00:17:02:3f:34 is the MAC address of ens3. Let's run through the top-level entries quickly:

  • log is an empty directory
  • The *.did-setup files are used internally by dracut to track status (it literally means dracut “did setup”)
  • The *.up files indicate the interface is up
  • net.ens3.lease is a dhclient lease file
  • net.ens3.dhcpopts is a shell-sourceable file containing a bunch of DHCP options with new_ prepended (e.g. new_broadcast_address, new_classless_static_routes, new_interface_mtu)
    • These look to be exactly the same values as in net.ens3.lease
  • net.ens3.gw contains an ip command to configure a gateway
    • On this particular instance, it's ip route replace default via 10.0.0.1 dev ens3
  • net.ens3.pid is a PID file
    • Examining the dracut code, this is a dhclient PID file, and that same dhclient invocation used net.ens3.lease as the lease file
  • net.ens3.resolv.conf: nameserver 169.254.169.254
  • net.ifaces contains just ens3
    • Looking at the dracut code, this is a list of interfaces (with just one entry for our case)
  • rwtab contains two lines, files /etc/sysconfig/network-scripts and files /var/lib/dhclient
    • I believe this is configuration for the read-only root that (I infer) dracut boots with, pulling those two directories into its writable scratch space

Now let's consider the state/ entries:

  • etc/resolv.conf is the same as net.ens3.resolv.conf
  • etc/sysconfig/network-scripts/ifcfg-ens3 is, as you might anticipate, a sysconfig file with network configuration for ens3; we'll break that down more below
  • var/lib/dhclient/dhclient-b560099e-e294-4563-bc2f-fe800312c96b-ens3.lease is identical to net.ens3.lease

The most interesting file of all of the above (from our perspective) is the sysconfig network configuration that dracut writes out (its full path is /run/initramfs/state/etc/sysconfig/network-scripts/ifcfg-ens3). The full content of the file is:

# Generated by dracut initrd
NAME="ens3"
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="b560099e-e294-4563-bc2f-fe800312c96b"
BOOTPROTO=dhcp
TYPE=Ethernet

This file is identical to /etc/sysconfig/network-scripts/ifcfg-ens3 in the booted system (including the first, commented line) except for a bunch of repeated NM_CONTROLLED=no lines.

I believe this contains all the information we would need to emit the appropriate cloud-init configuration (i.e. its name and the fact that it's a DHCP interface).

Path Forward

There are two potential paths forward:

  1. implement generic sysconfig network-scripts parsing (that could be used with net-convert, for example) and use that in cloud-init's dracut initramfs code, or

  2. implement parsing in cloud-init's dracut initramfs code which would handle only the dracut network configuration that we see generated.

I am leaning towards (2), implementing the parsing within the dracut code path. My feeling is that a generic parser is overkill for what we actually need to achieve here. If we keep the code contained within the dracut code path, then we can flesh it just as much as we need for the (probably) fairly simple network configurations that dracut can generate, without it seeming deficient when compared to the other network config parsers.

(Perhaps I'm being too conservative, and we can just implement a limited “generic” parser with the understanding that any future uses of it will have to expand it substantially.)

One important note: if implemented as part of the dracut code, the network-scripts parsing code should be structured so that it can easily be used as the basis for a more generic parser in future.

What do people think?

 
Read more...