Re: [openstack-dev] [nova] avahi-autoipd vs. nova networking (cloud-init)
On Sat, Mar 29, 2014 at 11:53:13AM -0400, Mike Spreitzer wrote: I run into trouble in Ubuntu VMs when avahi-autoipd is installed. After avahi-autoipd is installed, there is an extra route (number 2 in the [...] Of course, avahi-autoipd thinks it is doing me a favor. Nova thinks it is doing me harm. Which is right, and how do we achieve harmony? Why are you installing avahi-autoipd in your cloud instance? The autoipd tool is used for configuring network interfaces in the absence of either a static configuration or a functioning dhcp environment...and because you're running in a cloud environment, you're pretty much guaranteed the latter. If you really want zeroconf networking to be functional inside your instances while at the same time maintaining access to the OpenStack metadata service, you could add an explicit route to the metadata address via your default gateway. For example, given: # ip route default via 10.0.0.1 dev eth0 metric 100 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.4 169.254.0.0/16 dev eth0 scope link metric 1000 I would add: ip route add 169.254.169.254 via 10.0.0.1 And this restores access to the metadata service. This forces the kernel to pass traffic to 169.254.169.254 to the gateway, rather than assuming it's accessible via a local network. -- Lars Kellogg-Stedman l...@redhat.com | larsks @ irc Cloud Engineering / OpenStack | @ twitter pgpjmNHTFPbOK.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] avahi-autoipd vs. nova networking (cloud-init)
Lars Kellogg-Stedman l...@redhat.com wrote on 03/31/2014 01:31:57 PM: ... you could add an explicit route to the metadata address via your default gateway Yes, and there are other work-arounds possible too. I posted here because I was concerned there may be a bug that needs fixing. Why are you installing avahi-autoipd in your cloud instance? ... I did not explicitly ask for avahi-autoipd; it came as a consequence of installing xubuntu-desktop. BTW, I mis-identified some things in my original post. The cloud was not a recent DevStack install of the latest code; it was a non-DevStack install of Havana done a few months ago. I tested again with a cloud that *is* a recent DevStack install of the latest code, and used that to make an instance of http://cloud-images.ubuntu.com/precise/20140331/precise-server-cloudimg-amd64-disk1.img --- and in this case the extra route added by avahi-autoipd does *not* break routing to 169.254.169.254 !___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] avahi-autoipd vs. nova networking (cloud-init)
I run into trouble in Ubuntu VMs when avahi-autoipd is installed. This is when I install OpenStack using DevStack with a fairly plain local.conf. For example, make an instance of Ubuntu Server 12.04. You can reboot it, and all is well. Cloud-init continues to be able to read its metadata from 169.254.169.254. Here is an excerpt from the log (as shown in Horizon) of a successful reboot: cloud-init start-local running: Fri, 28 Mar 2014 15:24:45 +. up 3.46 seconds no instance data found in start-local ci-info: lo: 1 127.0.0.1 255.0.0.0 . ci-info: eth0 : 1 10.10.0.136 255.255.0.0 fa:63:63:c3:0c:b0 ci-info: route-0: 0.0.0.0 10.10.0.1 0.0.0.0 eth0 UG ci-info: route-1: 10.10.0.0 0.0.0.0 255.255.0.0 eth0 U cloud-init start running: Fri, 28 Mar 2014 15:24:45 +. up 3.99 seconds found data source: DataSourceEc2 Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd * Starting AppArmor profiles [80G [74G[ OK ] landscape-client is not configured, please run landscape-config. * Stopping System V initialisation compatibility[74G[ OK ] * Starting System V runlevel compatibility[74G[ OK ] * Starting regular background program processing daemon[74G[ OK ] * Starting save kernel messages[74G[ OK ] * Starting deferred execution scheduler[74G[ OK ] * Starting ACPI daemon[74G[ OK ] * Starting automatic crash report generation[74G[ OK ] * Stopping save kernel messages[74G[ OK ] * Starting CPU interrupts balancing daemon[74G[ OK ] * Stopping System V runlevel compatibility[74G[ OK ] * Starting execute cloud user/final scripts[74G[ OK ] cloud-init boot finished at Fri, 28 Mar 2014 15:24:58 +. Up 16.74 seconds After avahi-autoipd is installed, there is an extra route (number 2 in the excerpt below) that makes 169.254.169.254 unreachable. Here is an excerpt from the log of a reboot after avahi-autoipd is installed: cloud-init start-local running: Fri, 28 Mar 2014 18:39:24 +. up 5.10 seconds no instance data found in start-local ci-info: lo: 1 127.0.0.1 255.0.0.0 . ci-info: eth0 : 1 10.10.0.136 255.255.0.0 fa:63:63:c3:0c:b0 ci-info: route-0: 0.0.0.0 10.10.0.1 0.0.0.0 eth0 UG ci-info: route-1: 10.10.0.0 0.0.0.0 255.255.0.0 eth0 U ci-info: route-2: 169.254.0.0 0.0.0.0 255.255.0.0 eth0 U cloud-init start running: Fri, 28 Mar 2014 18:39:25 +. up 5.90 seconds 2014-03-28 18:39:28,821 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: url error [[Errno 113] No route to host] I have spared you all the bloody mess that follows. Of course, avahi-autoipd thinks it is doing me a favor. Nova thinks it is doing me harm. Which is right, and how do we achieve harmony? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
