Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1360839 - [RFE] Engine should support networks that have ipv6autoconf and DHCPv6 in parallel.
Summary: [RFE] Engine should support networks that have ipv6autoconf and DHCPv6 in par...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
low
low vote
Target Milestone: ovirt-4.2.6
: ---
Assignee: eraviv
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks: RHEV_IPv6 1403675
TreeView+ depends on / blocked
 
Reported: 2016-07-27 15:28 UTC by Edward Haas
Modified: 2018-09-06 08:09 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
In the past, it was only possible to attach a network to a host with an ipv6 address using either autoconf or dhcpv6. The two were mutually exclusive. In the current release, it is possible to enable both modes simultaneously using the Administration Portal or the REST API.
Clone Of:
Environment:
Last Closed: 2018-09-03 15:10:19 UTC
oVirt Team: Network
rule-engine: ovirt-4.2?
ylavi: ovirt-4.3?
mburman: testing_plan_complete-
rule-engine: planning_ack?
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 92777 master MERGED engine: poly dhcpv6 + autoconf iface config 2018-07-19 12:58:45 UTC
oVirt gerrit 92804 master ABANDONED engine: poly dhcpv6 + autoconf iface config 2018-07-05 07:15:04 UTC
oVirt gerrit 92819 master MERGED api-model: poly dhcpv6 + autoconf iface config 2018-07-16 05:34:36 UTC
oVirt gerrit 93037 model_4.2 MERGED api-model: poly dhcpv6 + autoconf iface config 2018-07-17 07:51:06 UTC
oVirt gerrit 93105 master MERGED restapi: Update to model 4.3.14 2018-07-19 10:31:47 UTC
oVirt gerrit 93107 ovirt-engine-4.2 MERGED restapi: Update to model 4.2.35 2018-07-20 16:32:10 UTC
oVirt gerrit 93178 ovirt-engine-4.2 MERGED engine: poly dhcpv6 + autoconf iface config 2018-07-20 16:32:13 UTC

Description Edward Haas 2016-07-27 15:28:02 UTC
Description of problem:

Actual results:
DHCPv6 and ipv6autoconf are currently under a radio button and both cannot be chosen.
A network may require both to be enabled, for example in cases where autoconf(RA) handles IP configuration and DHCP serves DNS entries.

Expected results:
User should be able to choose both options and have control of both independently.

Additional info:

Comment 1 Red Hat Bugzilla Rules Engine 2017-01-09 11:14:45 UTC
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Comment 2 Edward Haas 2018-07-25 03:54:01 UTC
@eraviv, could you please clarify why BZ/s 1597113 and 1595130 are blocking this issue?
They are perhaps limiting the usage of this option in two cases, but declaring them as blocking this feature is not clear to me.
Based on this relation, this BZ cannot be verified (as per my understanding).

Comment 3 eraviv 2018-07-25 04:42:58 UTC
The bug topic is 'engine should support'. So its down to the definition of 'support'.

1597113 prevents the creation of a storage domain on the host.
1595130 causes loss of connectivity of engine to host.

To my understanding these are basic functionalities without which, declaring engine as supporting this feature would be misleading from the perspective of a user. 
Likewise I think QE would not be able to verify the fix per the current definition of the bug.

Meni - whatever would make you happy to declare this as verified

Comment 4 Michael Burman 2018-07-25 13:51:06 UTC
(In reply to eraviv from comment #3)
> The bug topic is 'engine should support'. So its down to the definition of
> 'support'.
> 
> 1597113 prevents the creation of a storage domain on the host.
> 1595130 causes loss of connectivity of engine to host.
> 
> To my understanding these are basic functionalities without which, declaring
> engine as supporting this feature would be misleading from the perspective
> of a user. 
> Likewise I think QE would not be able to verify the fix per the current
> definition of the bug.
> 
> Meni - whatever would make you happy to declare this as verified

Eitan,
This RFE doesn't related to add host on top of IPv6 dhcp.
We also don't have any support for DHCP + autoconf in the lab.
We also don't have a support for dhcpv6 in the lab for our hosts. 
What was agreed with Dan, it to verify that i can attach networks to host with the new property DHCP + autoconf and make sure it is passed to vdsm correctly.
Please remove the blockers.

Comment 5 Michael Burman 2018-07-25 13:58:25 UTC
I see only "ipv6autoconf": true,
but             "dhcpv6": false, 
In UI i see both set, but on vdsm side only ipv6autoconf is true, dhcpv6 remain as false. 

- This is what engine is passed - 
ipv6BootProtocol='POLY_DHCP_AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null'

Moving back to assigned, tested on - 4.2.6_SNAPSHOT-84.gad3de30.0.scratch.master.el7ev with vdsm-4.20.35-1.el7ev.x86_64

Comment 6 Michael Burman 2018-07-25 14:04:32 UTC
The ifcfg-file looks ok

[root@zeus-vds1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-net-2
# Generated by VDSM version 4.20.35-1.el7ev
DEVICE=net-2
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=yes
DHCPV6C=yes
IPV6_AUTOCONF=yes

Comment 7 eraviv 2018-07-26 06:56:19 UTC
Burman,

in comment#5 you wrote: 

1. "I see only "ipv6autoconf": true,
but             "dhcpv6": false, 
In UI i see both set, but on vdsm side only ipv6autoconf is true, dhcpv6 remain as false."

- where do you see this? in getCaps vdsm reports both dhcpv6 and autoconf as true and in supervdsm.log the same.



2. "- This is what engine is passed - 
ipv6BootProtocol='POLY_DHCP_AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null'"

- this is what engine passes in setup networks to vdsm based on user selection. User is asking for a 'poly' ipv6bootproto, so of course there are no addr\prefix\gateway values because they are not set by the user under this option.

Comment 8 Michael Burman 2018-07-26 07:58:31 UTC
(In reply to eraviv from comment #7)
> Burman,
> 
> in comment#5 you wrote: 
> 
> 1. "I see only "ipv6autoconf": true,
> but             "dhcpv6": false, 
> In UI i see both set, but on vdsm side only ipv6autoconf is true, dhcpv6
> remain as false."
> 
> - where do you see this? in getCaps vdsm reports both dhcpv6 and autoconf as
> true and in supervdsm.log the same.
> 
> 
> 
> 2. "- This is what engine is passed - 
> ipv6BootProtocol='POLY_DHCP_AUTOCONF', ipv6Address='null',
> ipv6Prefix='null', ipv6Gateway='null'"
> 
> - this is what engine passes in setup networks to vdsm based on user
> selection. User is asking for a 'poly' ipv6bootproto, so of course there are
> no addr\prefix\gateway values because they are not set by the user under
> this option.

Eitan, 
I see this in vdsm-client Host getCapabilities - 
"ipv6autoconf": true
"dhcpv6": false,
Bot should be true and they not.

Comment 9 Michael Burman 2018-07-26 14:09:25 UTC
Talked with Dan and we need to fail this bug.

Engine do send it correctly to vdsm, in my case i don't have support for dhcpv6, so when vdsm does ifup on the network, it failing to get dhcpv6 and remain as dhcpv6=false.
So this flow is fine and will be finally done when the out-of-sync BZ 1607118 will be fixed(my network should have been out-of-sync in this case).
Engine say one thing and vdsm say something else.

But, the bug should be reassigned, because when engine collecting the data from vdsm it report it wrong.
We have modified vdsm to lie and say he has dhcpv6 and autoconf both true, but when doing refresh caps in the engine, it say only autoconf is enabled, but dhcpv6 isn't and that is problem when user will try to add host over IPv6 with both dhcpv6 and autoconf enabled.

do on the host - 
 }, 
        "net-2": {
            "ipv6autoconf": true, 
"dhcpv6": true,

after refresh caps in the engine 

 networkName='net-2', vdsmName='net-2', nicName='enp4s0', vlan='168', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='NONE', ipv4Address='nul
l', ipv4Netmask='null', ipv4Gateway='null', ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}]', removedNetworks=
'[]', bonds='[]', removedBonds='[]', clusterSwitchType='LEGACY'})

Comment 10 eraviv 2018-08-02 03:50:39 UTC
Following investigation, I found that if a change is made on the host such that both autoconf and dhcpv6 are enabled on a network (bridge) and vdsm reports this state to engine, engine supports this 'poly' state and reflects it as the actual state on the host as expected.

This reflection may appear for example as an out-of-sync indication if the user has configured ipv6 differently for the logical network. 
This reflection does not appear in the engine.log following a refresh-capabilities operation, because refresh-capabilities does not log the details reported by vdsm to engine.log

Comment 11 Michael Burman 2018-08-02 06:31:21 UTC
Ok, so BZ 1607118 will handle the out-pf-sync scenario.

Comment 12 Michael Burman 2018-08-02 06:37:40 UTC
Verified on - 4.2.6_SNAPSHOT-84.gad3de30.0.scratch.master.el7ev

u'net-2': {u'iface': u'net-2', u'ipv6autoconf': True, u'addr': u'', u'dhcpv6': True,

networks='[HostNetwork:{defaultRoute='false', bonding='false', networkName='net-2', vdsmName='net-2', nicName='enp4s0', vlan='168', vmNetwork='true', stp='false', properties='[]', ipv4BootProtocol='NONE', ipv4Address='null', ipv4Netmask='null', ipv4Gateway='null', ipv6BootProtocol='POLY_DHCP_AUTOCONF'

cat /etc/sysconfig/network-scripts/ifcfg-net-2
# Generated by VDSM version 4.20.35-1.el7ev
DEVICE=net-2
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=9000
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=yes
DHCPV6C=yes
IPV6_AUTOCONF=yes


Note You need to log in before you can comment on or make changes to this bug.