group.of.nepali.translators team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1689346

Title:
  cloud-init and nplan do not parse and use OpenStack networking
  correctly with netmask

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  On Openstack instances, cloud-init incorrectly rendered netplan
  configuration files.  The result is that networking does not work
  as expected.

  Note that this is not a default configuration on any Ubuntu provided images.
  Default images use ifupdown (eni) rendering which did not have this issue.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered netplan config to verify it has the correct format.
       The failed output would have 'addresses' with a format like:
       172.19.1.34/255.255.255.0
       The expected output would be 'cidr' format:
       172.19.1.34/24

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name

  ## get render tool
  $ wget https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py -O net-convert.py

  ## write the network_data.json
  $ cat >network_data.json <<EOF
  {
   "links": [
    {"ethernet_mac_address": "aa:ab:ac:ad:ae:00",
     "id": "tap1a", "type": "phy", "vif_id": "1a81968a"}
   ],
   "networks": [
     {"id": "network0", "ip_address": "172.19.1.34", "link": "tap1a",
      "netmask": "255.255.255.0", "network_id": "dacd568d", "type": "ipv4",
      "routes": [
       {"gateway": "172.19.3.254", "netmask": "0.0.0.0",
        "network": "0.0.0.0"}]}
   ],
   "services": [{"address": "172.19.0.12", "type": "dns"}]
  }
  EOF

  ## run the converter
  $ ./net-convert.py --network-data=network_data.json \
       --kind=network_data.json --output-kind=netplan \
       -m eth1,aa:ab:ac:ad:ae:00 --directory=./out.d 

  
  ## check the output
  $ cat out.d/etc/netplan/50-cloud-init.yaml
  network:
      version: 2
      ethernets:
          eth1:
              addresses:
              - 172.19.1.34/24
              match:
                  macaddress: aa:ab:ac:ad:ae:00
              nameservers:
                  addresses:
                  - 172.19.0.12
              routes:
              -   to: 0.0.0.0/0
                  via: 172.19.3.254
              set-name: eth1

  ## show the cloud-init versions
  $ dpkg-query --show cloud-init
  ...

  [Regression Potential] 
  The change is fairly safe in that it basically renders:
    172.19.1.34/24
  instead of
    172.19.1.34/255.255.255.0

  The previous rendering just plain did not work as it is not valid
  input for netplan.  So the regression path there should be low.

  The common code changes could shake out other failures in the networking
  path.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=16a7302f6a

  lxc-proposed-snapshot is
    https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.
  === End SRU Template ===

  
  networking data josn has:

  "ip_address" : "104.130.20.155",
  "netmask" : "255.255.255.0"

  "ip_address" : "10.184.3.234",
  "netmask" : "255.255.240.0",

  that got rendered into nplan as:
   - 104.130.20.155/255.255.255.0
   - 10.184.3.234/255.255.240.0

  which it failed to parse

  Stderr: Error in network definition //etc/netplan/50-cloud-init.yaml
  line 32 column 12: invalid prefix length in address
  '104.130.20.155/255.255.255.0'

  I believe nplan is expecing CIDR notation of /24 or some such. I
  belive the current plan is to fix cloud-init to generate /24 cidr
  notation in the nplan renderer.

  This needs SRU into xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1689346/+subscriptions