yahoo-eng-team team mailing list archive

[Andy Botting <andy@xxxxxxxxxxxxxxx>]

Public bug reported:

As fixed in bug #1749717, cloud-init will attempt to configure an
ephemeral ipv4 address on the first interface to fetch OpenStack (and
probably others) networking config via a metadata URL.

There's a couple of issues with this implementation that affect our
OpenStack cloud.

Access to our metadata server on 169.254.169.254 is delivered by an
additional route delivered by DHCP, which is not configured via cloud-
init's dhcp.py (that is probably another bug).

Also, we needed to bump up the timeouts for accessing our metadata, as
we're a largeish cloud and the defaults were way too low. We actually
copied the timeout/retry values from the Ec2 Datasource.

So the result is that users are left waiting for cloud-init-local stage
to timeout, as the additional route to the metadata server isn't
configured, which was 2 mins in our config.

I believe a simple fix for this situation would be to skip the ephemeral
ipv4 setup if the datastore config has apply_network_config: False

** Affects: cloud-init
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1821102

Title:
  Cloud-init should not setup ephemeral ipv4 if apply_network_config is
  False for OpenStack

Status in cloud-init:
  New

Bug description:
  As fixed in bug #1749717, cloud-init will attempt to configure an
  ephemeral ipv4 address on the first interface to fetch OpenStack (and
  probably others) networking config via a metadata URL.

  There's a couple of issues with this implementation that affect our
  OpenStack cloud.

  Access to our metadata server on 169.254.169.254 is delivered by an
  additional route delivered by DHCP, which is not configured via cloud-
  init's dhcp.py (that is probably another bug).

  Also, we needed to bump up the timeouts for accessing our metadata, as
  we're a largeish cloud and the defaults were way too low. We actually
  copied the timeout/retry values from the Ec2 Datasource.

  So the result is that users are left waiting for cloud-init-local
  stage to timeout, as the additional route to the metadata server isn't
  configured, which was 2 mins in our config.

  I believe a simple fix for this situation would be to skip the
  ephemeral ipv4 setup if the datastore config has apply_network_config:
  False

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