Bug 1236219

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.