Bug 1515880 - Don't allow to remove default route netwok from DC while still attached to hosts
Summary: Don't allow to remove default route netwok from DC while still attached to hosts
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.2.0
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-21 14:28 UTC by Michael Burman
Modified: 2020-07-03 09:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-19 16:44:14 UTC
oVirt Team: Network
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1576628 0 unspecified CLOSED default route validation fails when swapping default route networks 2021-06-10 16:17:57 UTC

Internal Links: 1576628

Description Michael Burman 2017-11-21 14:28:25 UTC
Description of problem:
Don't allow to remove a non-mgmt network with default route role from DC while still attached to the host.

We are allowing to remove from DC a non-mgmt network that is attached to the host and has a default route role for this host.
The expected result will be that the management network will set with the default route role, but the result is that it will be left as out-of-sync after the described scenario, as we not taking care to sync the management network after the non-mgmt network has removed from the DC.
- The default route will remain on the 'non-mgmt' network although it is already 'unmananged' network in the engine, but still attached to the host and the routing is from the non-mgmt network.

The options are:
- Block such scenario and don't allow to remove a non-mgmt network from DC while still attached to the host and has the default route role
- Engine should invoke sync on the management network 

Version-Release number of selected component (if applicable):
4.2.0-0.5.master.el7

How reproducible:
100%

Steps to Reproduce:
1. Host with management network which is the default route network as well(default one)
2. Create network 'non-mgmt'
3. Attach 'non-mgmt' network to the host and set bootproto
4. Set 'non-mgmt' network with default route role via 'Clusters'>'Networks' flow or via 'Networks'>'Clusters' flow - the default route is now via 'non-mgmt' network
5. Remove 'non-mgmt' network from the DC

Actual results:
- 'non-mgmt' network is 'unmanaged' network and that is expected.
- management network has now the default route role icon, but it is out-of-sync because we didn't sent any setup networks command or invoked sync to update the default route property on the host. 
- The route is still via 'non-mgmt' network and not the management network as should be for such scenario.

Expected results:
- Block such scenario from happening
- If allowing, then sync the management network so the routing will be via the management network and not via the deleted network 
- I think that the best will be to block the removal of a non-mgmt default route network from the DC if it's still attached to the host.

Additional info:
https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/workitem?id=RHEVM-21390

Comment 1 Michael Burman 2017-11-21 14:38:52 UTC
The main issue after ending up with such scenario(except that the route is still from the non-mgmt network) is that it is not possible to sync back the management network with error of 'Only a single default route network is allowed' in vdsm side. 

- To work around such scenario we first will need to remove the 'unamanged' network and only then to sync the management network.
It means 2 manual interventions to make the host synced again with the correct default route.

Comment 2 Michael Burman 2017-11-21 14:56:15 UTC
The same will happen if the non-mgmt network is not attached to the host, we will not sync the management network as well in case of a non-mgmt network with default route role removal from the DC. The host will remain without a default route in such scenario, until the manual sync.

Comment 3 Dan Kenigsberg 2017-11-22 08:38:05 UTC
I don't like to add more validations to Engine; instead we should make sure we keep the hosts in manageable state after removal of such network.

Comment 4 Michal Skrivanek 2020-03-19 15:15:14 UTC
doesn't seem to be required by 4.4 GA, moving to 4.4.3 for further prioritization

Comment 5 Dominik Holler 2020-03-19 16:44:14 UTC
The connectivity check of the host ensures already that the host does not loose connectivity because of miss configuration via oVirt


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