Description of problem: Require boot protocol for a network that is set to be the Default Route network role. Currently we allow to choose a network with the new network role - 'Default Route' without any ip configuration, which is wrong and has no meaning. The behaviour should the same as we have for all other networks roles that require ip configuration(dhcp or static). See BZ - 1163365 If we choosing a network to be a 'Default Route' role, we must require a bootproto for it(no matter if it's attached already to the host or not) Version-Release number of selected component (if applicable): 4.2.0-0.0.master.20170402072517.gitb0c121a.el7.centos How reproducible: 100% Steps to Reproduce: 1. Create new network 2. Set it as the 'Default Route' network via Clusters>Networks or Networks>Clusters 3. Attach the network to the host via setup networks dialog. 4. Create new network and attach to host without setting bootproto 5. Set it as the 'Default Route' network via Clusters>Networks or Networks>Clusters Actual results: Steps 3 and 5 are allowed Expected results: 3. Error while executing action: camel-vdsa.qa.lab.tlv.redhat.com: Cannot setup Networks. Role (migration/display/gluster) network 'mb1' hasn't boot protocol assigned. 5. Should fail with error: Error while executing action: Cannot edit Network. IP address has to be set for the NIC that bears a role network. Network: mb14, Nic: bond0 on host orchid-vds1.qa.lab.tlv.redhat.com violates that rule. Additional info: See also - https://bugzilla.redhat.com/show_bug.cgi?id=1163365
question: ad "The behaviour should the same as we have for all other networks roles that require ip configuration(dhcp or static). " Searching I found out, that ip is checked for 'role networks', which are defined as follow: public static boolean isRoleNetwork(NetworkCluster networkCluster) { return networkCluster.isDisplay() || networkCluster.isMigration() || networkCluster.isGluster(); } and check is done on nic, which is bound to given network using network attachment. So according to this, I should be able to move display, migration and gluster roles to network, which is not attached and does not have any IP at all. And I am able to do that. So if we want to work equally for default route it's easy, just modify method mentioned above. But that will allow to denote network as defaultRoute/migration etc. even if it's not attached. But if it's not attached, is check even doable? Isn't it possible for network not have IP/bootproto information configured by engine? If it is possible, we might simply disallow modification of network, which is not attachech. But it can be attached in only some hosts and not all ... please advice, what's expected behavior.
I need help with what is expected. I cannot see a way how to implement requested (network does not have ip configuration) and request: "The behaviour should the same as we have for all other networks roles that require ip configuration(dhcp or static)" is iiuc already met. No checks are done in that case for unattached networks.
> So if we want to work equally for default route it's easy, just modify method mentioned above yes, I believe that't the correct solution for this bug. > But that will allow to denote network as defaultRoute/migration etc. even if it's not attached I am not sure I understand your question. I believe that this is the case with other roles as well, and I do not see that the case of default_route is any different. If someone grants a role to a network, he should also keep the net as required. If he changes it to non-required, and does not attach it to hosts, he should expect trouble.
ok, fine. So I'll implement this, as you flagged it as correct solution. All I was saying is, that (even if network is flagged as required) will not guarantee, that network with defaultRoute/migration/etc. role will have boot proto, because only new/modified network_attachments will be validated. Btw. migration role allows boot proto for either ipv4 or ipv6. Others requires always only ipv4. How about default route? Also only ipv4?
It depends, default route feature supports IPv6? if so then IPv6 is valid too.
Verified on - 4.2.0-0.0.master.20170702100738.git46a9f67.el7.centos
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.