Bug 1519271

yes 'etho' is a typo. 

Regarding sysconfig for both ipv4 and ipv6 dhcp - Thomas can you answer?

how about

IPV6INIT=yes
IPV6_AUTOCONF=yes

?

as (In reply to Thomas Haller from comment #6)
> how about
> 
> IPV6INIT=yes
> IPV6_AUTOCONF=yes
> 
> ?

As far as we have managed to test on cloud-init 0.7.9-9, 'autoconf' was not supported. 
Ryan?

(In reply to eraviv from comment #7)
> as (In reply to Thomas Haller from comment #6)
> > how about
> > 
> > IPV6INIT=yes
> > IPV6_AUTOCONF=yes
> > 
> > ?
> 
> As far as we have managed to test on cloud-init 0.7.9-9, 'autoconf' was not
> supported. 
> Ryan?

The NM docs (Table 42) at https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html indicates that IPV6_AUTOCONF should not be set to yes for ipv6 dhcp.

you are right, sorry. I think it should be 

IPV6INIT=yes
IPV6_AUTOCONF=no
DHCPV6C=yes

for DHCP.

(In reply to Thomas Haller from comment #9)
> you are right, sorry. I think it should be 
> 
> IPV6INIT=yes
> IPV6_AUTOCONF=no
> DHCPV6C=yes
> 
> for DHCP.

This is what we have now, except for not explicitly setting IPV6_AUTOCONF to no (I believe this is how it defaults):


BOOTPROTO=dhcp
DEVICE=eth0
DHCPV6C=yes
IPV6INIT=yes
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

The intent is to have both ipv4 and ipv6 for the interface.

Eitan, are there any errors logged that may be helpful in figuring out what's going wrong?

reply to Ryan McCabe from comment #10)
> 
> The intent is to have both ipv4 and ipv6 for the interface.

Sorry, meant both ipv4 and ipv6 dhcp for the interface here.

Sorry -- It appears I have misread the table initially and that the default for AUTOCONF is IPV6_AUTOCONF=!IPV6FORWARDING and the default for IPV6FORWARDING is yes, thus autoconf will default to yes. I will make a build that explicitly sets it to no and let's see if that resolves the issue.

Created attachment 1369022 [details]
bootproto contents for various scenarios with cloud-init v. 0.7.9-20-test

looks like  cloud-init v. 0.7.9-20-test solves the issue:

I tested both static and dhcp (with ipvX_dhcp notation) for:
- only ipv4
- only ipv6
- both

and got expected outcome in eth0 configuration. also had ping + login with expected ip addresses.

Hi, Ryan
I tried ot verify this bug using build 20, but still have same problem
CLoud-init version : 0.7.9-20.el7.x86_64

Network config:
  "availability_zone" : "nova",
  "hostname" : "cloud20",
  "launch_index" : "0",
  "meta" : {
    "role" : "server",
    "dsmode" : "local",
    "essential" : "false"
  },
  "name" : "cloud20",
  "uuid" : "3803da95-f2ea-460a-8b2f-5fd29e215b52"
  "links" : [ {
    "name" : "eth0",
    "id" : "eth0",
    "type" : "vif"
  } ],
  "networks" : [ {
    "netmask" : "255.255.255.0",
    "link" : "eth0",
    "id" : "eth0",
    "ip_address" : "10.0.0.1",
    "type" : "ipv4",
    "gateway" : "10.0.0.254"
  }, {
    "link" : "eth0",
    "id" : "eth0",
    "type" : "dhcp6"
  } ]


Actual ifcfg:
BOOTPROTO=dhcp
IPADDR=10.0.0.1
....

So we don't have any mentions of IPv6 here and IPv4 is set to dhcp

(In reply to Vladimir from comment #17)
> Hi, Ryan
> I tried ot verify this bug using build 20, but still have same problem
> CLoud-init version : 0.7.9-20.el7.x86_64
> 
>   }, {
>     "link" : "eth0",
>     "id" : "eth0",
>     "type" : "dhcp6"

This should be "ipv6_dhcp" not "dhcp6." What produced the json?

There is also a missing comma after the uuid.

It's RHEV 4.2.0.2-0.1.el7 (downstream build)

(In reply to Vladimir from comment #20)
> It's RHEV 4.2.0.2-0.1.el7 (downstream build)

I am not sure I understand what produced the json.
Is this a RHEVM 4.2.0, i.e. an ovirt-engine rpm? d/s ovirt-engine still does not contains the ipvX_dhcp notation (it is in u/s since yesterday only). also AFAIK, ovirt-engine has never put a 'meta' part in the json, nor a uuid.

Is there downstream build with this ipvX_dhcp notation support?

Meanwhile I tried this with cloud_init 0.7.9-20 on local VM and still had no success

Here is the network_data:
[root@localhost ~]# cat /mnt/latest/network_data.json 
{
  "links" : [ {
    "name" : "eth1",
    "id" : "eth1",
    "type" : "vif"
  } ],
  "services" : [ {
    "address" : "88.8.8.8",
    "type" : "dns-nameserver"
  }, {
    "address" : "search.foo.bar",
    "type" : "dns-search"
  } ],
  "networks" : [ {
    "netmask" : "255.255.255.0",
    "link" : "eth1",
    "id" : "eth1",
    "ip_address" : "10.0.0.1",
    "type" : "ipv4",
    "gateway" : "10.0.0.254"
  }, {
    "link" : "eth1",
    "id" : "eth1",
    "type" : "ipv6_dhcp"
  } ]
}

And here is the resulting ifcfg:
[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=dhcp
DEFROUTE=yes
DEVICE=eth1
GATEWAY=10.0.0.254
IPADDR=10.0.0.1
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

Are you sure you're using the -20 build, and that it's provided the input you pasted above? If I test it, I get:

# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth1
DHCPV6C=yes
GATEWAY=10.0.0.254
IPADDR=10.0.0.1
IPV6INIT=yes
IPV6_AUTOCONF=no
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

hi Ryan,
When do you expect this fix to be available downstream?

Thanks

This should be in the -20 build. Is it not working for you?

Our QE wants to know if this is incorporated downstream already so they can test downstream.

The package with the fix has not been officially released yet, if that's what you're asking. It will be released with RHEL 7.5, unless somebody requests a z-stream for this issue.

Am I understanding the question correctly?

Verified on RHEVM 4.2.1.1-0.1.el7 with cloud-init-0.7.9-22.el7
User all possible configurations of IPv4 + IPv6 on the same interface + general verification

moving to verified according to comment 28

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0806

Which build and what exactly should we test?

The current RHEL 7.5 build would be best to test, IMO. It is https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=653899

I've run our scenarios against this build, all tests passed