yahoo-eng-team team mailing list archive

[Ahmed Rahal <arahal@xxxxxxxx>]

Public bug reported:

This happens on centos release 6.5 (probably previous versions as well).
VM runs in an openstack Havana kvm compute node.

At boot, the system init scripts set IP addresses from configuration files (we do not use dhcp).
Later on in the boot process, cloudinit gets called.
At that point, cloud-init fetches IP configuration (in our case, from configdrive) and tries to ifup the interfaces.
On first launch, there were no IP addresses in the local config files, cloudinit runs ifup and all is fine.
On subsequent launches, configuration files already provided relevant IP information and IPs are already set, so when cloudinit fires up, we get this on the console:

__init__.py[WARNING]: Running ['ifup', 'eth0'] resulted in stderr output: RTNETLINK answers: F
ile exists

This is not critical as the correct IP is already set. It is just an
annoying warning.

However, we run on a remote storage backend and do clone the volumes.
In that case, once we boot off the cloned volume, the old IPs are still in the configration files, and get temporarily assigned to interfaces. As soon as cloudinit kicks in, new IPs are fetched from the configdrive and interfaces are ifup-ed.
The new IPs get assigned to the interfaces, but, the old IPs are still there. So until the next reboot, the old IPs stick to the interfaces potentially creating havoc in that new VM.

To avoid any side-effect, we added a _bring_down_interface() method that we call off a rhel specific overload of _bring_up_interface(). 
We fixed this in:
cloud-init/cloudinit/distros/__init__.py
cloud-init/cloudinit/distros/rhel.py

This bug serves the purpose of documenting the case and hopefully
merging the fix

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

** Patch added: "add _bring_down_interface()"
   https://bugs.launchpad.net/bugs/1275098/+attachment/3964722/+files/0001-added-_bring_down_interface.patch

-- 
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/1275098

Title:
  iface setup on centos does not remove previously set IPs

Status in Init scripts for use on cloud images:
  New

Bug description:
  This happens on centos release 6.5 (probably previous versions as well).
  VM runs in an openstack Havana kvm compute node.

  At boot, the system init scripts set IP addresses from configuration files (we do not use dhcp).
  Later on in the boot process, cloudinit gets called.
  At that point, cloud-init fetches IP configuration (in our case, from configdrive) and tries to ifup the interfaces.
  On first launch, there were no IP addresses in the local config files, cloudinit runs ifup and all is fine.
  On subsequent launches, configuration files already provided relevant IP information and IPs are already set, so when cloudinit fires up, we get this on the console:

  __init__.py[WARNING]: Running ['ifup', 'eth0'] resulted in stderr output: RTNETLINK answers: F
  ile exists

  This is not critical as the correct IP is already set. It is just an
  annoying warning.

  However, we run on a remote storage backend and do clone the volumes.
  In that case, once we boot off the cloned volume, the old IPs are still in the configration files, and get temporarily assigned to interfaces. As soon as cloudinit kicks in, new IPs are fetched from the configdrive and interfaces are ifup-ed.
  The new IPs get assigned to the interfaces, but, the old IPs are still there. So until the next reboot, the old IPs stick to the interfaces potentially creating havoc in that new VM.

  To avoid any side-effect, we added a _bring_down_interface() method that we call off a rhel specific overload of _bring_up_interface(). 
  We fixed this in:
  cloud-init/cloudinit/distros/__init__.py
  cloud-init/cloudinit/distros/rhel.py

  This bug serves the purpose of documenting the case and hopefully
  merging the fix

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