We distribute /usr/share/nova/interfaces.template that looks like this: DEVICE="{{ name }}" NM_CONTROLLED="no" ONBOOT=yes TYPE=Ethernet BOOTPROTO=static IPADDR={{ address }} NETMASK={{ netmask }} BROADCAST={{ broadcast }} GATEWAY={{ gateway }} DNS1={{ dns }} #if $use_ipv6 IPV6INIT=yes IPV6ADDR={{ address_v6 }} #end if There are two problems here: 1. The get_injected_network_template function (in nova.virt.netutils) does not call this with top-level keys matching the ones used in the template, so all the references there (e.g., {{ name }}) expand to the empty string. The template actually receives a top-level 'interfaces' key with a list of network interfaces to inject. We could fix this template, but... 2. cloud-init expects a debian-ish "/etc/network/interfaces" format (see, e.g., cloudinit/distros/rhel.py). So in fact we need a template that looks like this: {% for interface in interfaces %} auto {{ interface.name }} iface {{ interface.name }} inet static address {{ interface.address }} netmask {{ interface.netmask }} broadcast {{ interface.broadcast }} gateway {{ interface.gateway }} dns-nameservers {{ interface.dns }} {% endfor %}
Reopening this as it is still relevant for OSP12. Instances using configdrive (provider network, no dhcp possible) end up with: $ cat /mnt/test/openstack/content/0000 DEVICE="" NM_CONTROLLED="no" ONBOOT=yes TYPE=Ethernet BOOTPROTO=static IPADDR= NETMASK= BROADCAST= GATEWAY= DNS1= #if $use_ipv6 IPV6INIT=yes IPV6ADDR= IMHO we should consider using the default template: https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template or provide a way to inject it into the nova container during the deployment (ideally without having to create new container). Additionally I think we should document that in order for cloud-init to make use of such template the flat_injected parameter should be set to true, either extending puppet-nova or by using nova_config like: parameter_defaults: ExtraConfig: nova::config::nova_config: DEFAULT/flat_injected: value: true
Hi Luca, I tried to reproduce it with below steps, but couldn't get the exact content of interface mentioned by you in comment#3. 1) After fresh deployment of OSP12, I have set flat_injected=true in /etc/nova/nova.conf on overcloud nodes. Then I have created a provider network. openstack network create --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 10 external 2) Create subnet without dhcp. openstack subnet create --network external --subnet-range 10.0.0.0/24 --allocation-pool start=10.0.0.10,end=10.0.0.150 --dns-nameserver 8.8.8.8 --no-dhcp ext_subnet 3) upload cirros image to glance. openstack image create --file cirros-0.4.0-x86_64-disk.img centos_img 4) I have created required security group, applied rules to security group and created keypair as well. openstack security group create sg1 openstack security group rule create --protocol icmp sg1 openstack security group rule create --protocol tcp --dst-port 22 sg1 openstack keypair create test_keys > ~/test_keys.pem 4) Create instance with config drive. openstack server create --image centos_img --flavor m1.test --nic net-id=external --key-name test_keys --security-group sg1 --config-drive true test_vm After instance creation, I couldn't access vm through assigned IP. I could see instance disk config on /var/lib/nova/instance/<instance_id>/disk.config location, I tried to mount it to see its contents, but couldn't find content directory in it. It seems that I might have missed something or done something wrong, would you please provide proper reproduction steps.
Hi Rajesh, the only difference that I can see is that I deploy with: nova::config::nova_config: DEFAULT/config_drive_cdrom: value: true DEFAULT/flat_injected: value: true but regardless of whether I set config_drive_cdrom to true or false I consistently see a "sr0" device in my instance. I've tested both cirros 3.5 and cirros 4, same result: /dev/root resized successfully [took 1.26s] ____ ____ ____ / __/ __ ____ ____ / __ \/ __/ / /__ / // __// __// /_/ /\ \ \___//_//_/ /_/ \____/___/ http://cirros-cloud.net login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root. test-vm3 login: cirros Password: $ sudo -i # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 464K 0 rom vda 253:0 0 1G 0 disk |-vda1 253:1 0 1015M 0 part / `-vda15 253:15 0 8M 0 part # mount /dev/sr0 /mnt/ # find /mnt /mnt /mnt/ec2 /mnt/ec2/2009-04-04 /mnt/ec2/2009-04-04/meta-data.json /mnt/ec2/latest /mnt/ec2/latest/meta-data.json /mnt/openstack /mnt/openstack/2012-08-10 /mnt/openstack/2012-08-10/meta_data.json /mnt/openstack/2013-04-04 /mnt/openstack/2013-04-04/meta_data.json /mnt/openstack/2013-10-17 /mnt/openstack/2013-10-17/meta_data.json /mnt/openstack/2013-10-17/vendor_data.json /mnt/openstack/2015-10-15 /mnt/openstack/2015-10-15/meta_data.json /mnt/openstack/2015-10-15/network_data.json /mnt/openstack/2015-10-15/vendor_data.json /mnt/openstack/2016-06-30 /mnt/openstack/2016-06-30/meta_data.json /mnt/openstack/2016-06-30/network_data.json /mnt/openstack/2016-06-30/vendor_data.json /mnt/openstack/2016-10-06 /mnt/openstack/2016-10-06/meta_data.json /mnt/openstack/2016-10-06/network_data.json /mnt/openstack/2016-10-06/vendor_data.json /mnt/openstack/2016-10-06/vendor_data2.json /mnt/openstack/2017-02-22 /mnt/openstack/2017-02-22/meta_data.json /mnt/openstack/2017-02-22/network_data.json /mnt/openstack/2017-02-22/vendor_data.json /mnt/openstack/2017-02-22/vendor_data2.json /mnt/openstack/content /mnt/openstack/content/0000 /mnt/openstack/latest /mnt/openstack/latest/meta_data.json /mnt/openstack/latest/network_data.json /mnt/openstack/latest/vendor_data.json /mnt/openstack/latest/vendor_data2.json Maybe I can have a look at your environment? I am using the 12.0-20180124.1 images fwiw.
I've tried with the latest docker images available (20180309) and the configdrive now contains valid ip/mask info for both a single nic and multiple nics: # cat /mnt/openstack/content/0000 # Injected by Nova on instance boot # # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static hwaddress ether fa:16:3e:52:54:c9 address 10.0.0.13 netmask 255.255.255.0 broadcast 10.0.0.255 gateway 10.0.0.1 dns-nameservers 8.8.8.8 auto eth1 iface eth1 inet static hwaddress ether fa:16:3e:f0:62:6c address 10.2.0.17 netmask 255.255.255.0 broadcast 10.2.0.255 gateway 10.2.0.1 dns-nameservers 8.8.8.8 I've tested ubuntu 18, centos7 and cirros and only cirros is still showing the issue: # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:52:54:c9 brd ff:ff:ff:ff:ff:ff inet6 fe80::f816:3eff:fe52:54c9/64 scope link valid_lft forever preferred_lft forever I've tried using the nova-provided interfaces.template and cirros still does not configure the ip address, so I would consider this an issue with cirros-init as cloud-init seems to be doing the right thing regardless of the configdrive format. Thoughts?
Hi, I have also tried with OSP12 as well as master branch. I think your finding are correct, there is no issue with centos images. I could get valid ip/mask with configdrive. Can we close this issue in that case ?
(In reply to Rajesh Tailor from comment #7) > Hi, > > I have also tried with OSP12 as well as master branch. > I think your finding are correct, there is no issue with centos images. I > could > get valid ip/mask with configdrive. > > Can we close this issue in that case ? I think we should try to track down the change/patch that fixed this issue and see if it is backportable to newton. I don't have much time today but I'll try to have a look at the code, any help would be appreciated :)
I tried to check the changelog for nova, yet couldn't find anything related, which looks like fixed this issue. Did you get anything related ? Is the issue persist in newton ? In that case, we might need to clone this BZ or open a new BZ for RHOS10.
(In reply to Rajesh Tailor from comment #9) > I tried to check the changelog for nova, yet couldn't find anything related, > which looks like fixed this issue. > Did you get anything related ? > > Is the issue persist in newton ? > In that case, we might need to clone this BZ or open a new BZ for RHOS10. Hi Rajesh, I am working on reproducing this issue on osp10 and 11. On osp12 I get inconclusive results - the past days I was able to consistently reproduce the issue but after I've redeployed my lab I can't anymore. I think the issue might depend not that much on the interfaces.template itself but on the jinja2 rendering. I'll try pdb'ing nova and I'll update this bz as soon as I have something. Luca
Closing this bug because of lack of response. If you think the issue persist, Please try to reproduce again and file a separate bug.