Neither Vdsm not Engine control ipv6 routing. This is a low priority rfe.

*** Bug 1571869 has been marked as a duplicate of this bug. ***

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 ?.

raising severity because this blocks bug 1607118

The solution to this issue will be as follows:
- prevent setup networks for a 'default route' role network if it has not been
  configured with an ipv4 configuration.
- prevent move the 'default route' role to a network which is attached to a host
  without an ipv4 configuration.'

This is because the default route role in engine is a mirror for the creation of an ipv4
default route on the host. The default route role is not related to ipv6 configuration or
routing.

Michael, pls ack this solution. Thanks

Hi Eitan,
This solutions are already exist)

- "Error while executing action: Cannot edit Network. IP address has to be set for the NIC that bears a role network. Network: net-1, Nic: enp6s0 on host host1 violates that rule."

We have such validation for a long time now. All roles must be set with bootproto, without it you can't attach the network to a host nor update an attached network with such role, if bootproto wasn't set

Also, how could it be that you added a fixed in version, if the bug is on post state? it's couldn't be)
We already got the build. so this is not correct, please remove.

This solution exists in the following manner:
if the network is has any role then it should have either ipv4 or ipv6 configuration.

But in the case of only ipv6 configuration on a default route network it causes an out-of-sync on the attachment because in engine the attachment 'has default route' while on the host nic it does not have, because without ipv4 configuration vdsm does not make the nic a default route. so this fix will create a special validation for the default route role - that it must specifically have an ipv4 configuration and not just 'any configuration'. the old validation for the other roles will stay the same.

So you say that, in case of default route role, we will now validate that network has a IPv4 bootproto specifically, so my questions are:

1. Do this gonna cover both flows?
- While attaching the network to a host 
- While network already attached to the host and you set it with default route role

2. Will the validation error messages gonna change?

3. Will this brake our automation for default route feature tests? do we need to adjust our code because of this fix? 

Thanks,

4. Will this fix the out-of-sync issue on add host?

1. It will cover both flows.

2. There will be two new validation messages for each flow - each message consistent with the existing messages:

any role error messages (existing):
Cannot setup networks. Role (migration/display/gluster) network '${networkName}' has no boot protocol assigned.
Cannot setup networks. IP address has to be set for the NIC that bears a role network. Network\: ${NetworkName}, Nic\: ${nicName} on host ${hostName} violates that rule.


default role error messages (new):
Cannot setup networks. Network '${networkName}' is assigned the 'Default Route' role but has no IPv4 boot protocol assigned.
Cannot setup networks. IPv4 address has to be set for the NIC that bears a 'Default Route' role network. Network\: ${NetworkName}, Nic\: ${nicName} on host ${hostName} violates that rule.




3. Depends on what you test in the automation. If you test existence of an error - there will still be an error. If you test message content - then it will break.

4. No, we have to think some more about this scenario. it is problematic, because if on ovirt-mgmt exists, it automatically receives all roles, but if it has only ipv6 then it will become out-of-sync immediately. any ideas?

I think point (4) is part of BZ 1403675

currently default_route role means "set defaultRoute=True".

imho we should modify the meaning to:
- if there is an ipv4 address, set defaultRoute=True
- if there is an ipv6 address, set ipv6gateway=whatever-is-defined-on-engine

Following an off-line discussion we will go with a different solution:

The Default Route Role (DRR) will be used for both v4 and v6 families:
- On completion of 'add host' ovirtmgmt will be out-of-sync only if the host did not report a gateway at all for it (neither v4 nor v6)
- On setup networks - if a network is DRR it will not be possible to configure it without at least one static gateway or at least one dynamic family addressing.
- On set DRR in the cluster - it will not be possible to set a network as DRR unless it has at least one reported or one configured gateway on either v4 or v6. 
- Of all statically configured v6 gateways a user sets, only the one on which the current DRR is set will be passed to the host.
  corollary: if there is a statically configured v6 gateway on a non-DRR network - no gateway will be reported by getCaps for the interface but the network will nevertheless be in-sync.

Dan's suggested modification "if there is an ipv4 address, set defaultRoute=True" causes the following behaviour:

For example, if host has ipv4 configured with dhcp before adding it to engine:
1. on 'add host' setup networks does not find an ipv4 gateway in engine configuration of ovirtmgmt and there is no such gateway in the host ifcfg, so engine sends defaultRoute=false
2. vdsm sets defaultRoute=false on ifcfg and reports the same back to engine. 

==> out of sync on ipv4 because ovirtmgmt is configured as the defaultRoute network
==> user has to change the ipv4 configuration on the attachment to static and run setup networks again for the network to be in sync

Dan, am I missing sth?

Dan's suggestion from above is implemented in the solution as follows:

The meaning of the default route role changes. 
It now signifies a network which provides either v4 or v6 default routes on a host.

According to this meaning the configuration of a  NIC on the host is in sync with the default route role if it is configured in either of the following manners:
- with both a v4 gateway and a DEFROUTE=true flag (aka ipv4defaultRoute in vdsm speak).
- with a v6 gateway.

Engine will consider the network attachment in sync with the host NIC if and only if the network is designated as the default route role in engine and the NIC has one of the corresponding configurations as described above.

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Eitan , please move to MODIFIED if all relevant patches were merged. Thanks,

Notes for this RFE - 

1. When the default route role is moved away from a network, its ipv6 gateway is automatically removed from the interface.
2. In the main 'Alerts' notification drawer, an alert notification will alert that "On cluster golden_env_mixed_1 the 'Default Route Role' network is no longer network ovirtmgmt. The IPv6 gateway is being removed from this network."
3. After moving the default route role to a new network the user should set a static ipv6 gateway on this network - The network will be shown as out-of-sync(because of the default route property - the tooltip should be addressed and improved in future in BZ 1670341)
4. If the host and engine are not on the same SUBNET, engine will loose connectivity with the host on moving the default route role between networks. This is due to result (1). The user should take precautions to avoid this situation. 

Verified on - 4.3.1.1-0.1.el7 and vdsm-4.30.9-1.el7ev.x86_64

This bugzilla is included in oVirt 4.3.1 release, published on February 28th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.1 release, it has been closed with a resolution of CURRENT RELEASE.

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

I am describing this limitation in the 4.3 documentation: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3-beta/html/administration_guide/chap-logical_networks#Configuring_a_Default_Route