| 2014-01-31 22:04:03 |
Ahmed Rahal |
bug |
|
|
added bug |
| 2014-01-31 22:04:03 |
Ahmed Rahal |
attachment added |
|
add _bring_down_interface() https://bugs.launchpad.net/bugs/1275098/+attachment/3964722/+files/0001-added-_bring_down_interface.patch |
|
| 2014-01-31 22:04:45 |
Ahmed Rahal |
attachment added |
|
bring dow interface before interface up https://bugs.launchpad.net/cloud-init/+bug/1275098/+attachment/3964723/+files/0002-bring-dow-interface-before-interface-up.patch |
|
| 2014-01-31 22:14:15 |
Ahmed Rahal |
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 |
This happens on centos release 6.5 (probably previous versions as well).
VM runs in an openstack Havana kvm compute node.
cloud-init 0.7.2
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 |
|
| 2014-02-03 17:38:09 |
Ahmed Rahal |
description |
This happens on centos release 6.5 (probably previous versions as well).
VM runs in an openstack Havana kvm compute node.
cloud-init 0.7.2
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 |
This happens on centos release 6.5 (probably previous versions as well).
VM runs in an openstack Havana kvm compute node.
cloud-init 0.7.2
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: File 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 |
|
| 2014-02-18 15:25:06 |
Ahmed Rahal |
attachment added |
|
ifdown_before_ifup https://bugs.launchpad.net/cloud-init/+bug/1275098/+attachment/3985381/+files/ifdown_before_ifup.patch |
|
| 2014-09-12 16:29:13 |
Scott Moser |
marked as duplicate |
|
1225922 |
|
| 2014-10-01 17:55:33 |
Kenneth Burger |
bug |
|
|
added subscriber Kenneth Burger |
| 2015-04-21 21:05:07 |
Launchpad Janitor |
branch linked |
|
lp:cloud-init |
|
| 2017-01-31 11:10:02 |
Markus |
bug |
|
|
added subscriber Markus |
