Bug 1021649

Summary:	Keep existing bond and bridge configurations or tell the user that they will be lost
Product:	[Retired] oVirt	Reporter:	Fabian Deutsch <fdeutsch>
Component:	ovirt-engine-core	Assignee:	Moti Asayag <masayag>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3	CC:	acathrow, bazulay, cshao, danken, dougsland, fdeutsch, gouyang, hadong, huiwa, iheim, leiwang, myakove, yaniwang, ycui, yeylon
Target Milestone:	---	Keywords:	Triaged
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	network
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-16 10:41:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	920171

Description Fabian Deutsch 2013-10-21 17:32:21 UTC

Description of problem:
Node let's the user create bond's and bridges at installtime or at runtime.
There should be (a) a way to migrate this layout to engine if possible or (b) tell the user that the existing layout can not be migrated

Comment 1 Alon Bar-Lev 2013-10-21 17:55:02 UTC

Moti, have no idea what it is about... but should be done post-deploy...

Comment 2 Fabian Deutsch 2013-10-21 19:27:47 UTC

(In reply to Alon Bar-Lev from comment #1)
> Moti, have no idea what it is about... but should be done post-deploy...

Alon,

so what can I do to make this clearer?

Comment 3 Moti Asayag 2013-10-22 09:36:33 UTC

(In reply to Fabian Deutsch from comment #2)
> (In reply to Alon Bar-Lev from comment #1)
> > Moti, have no idea what it is about... but should be done post-deploy...
> 
> Alon,
> 
> so what can I do to make this clearer?

The ovirt-engine reflects the actual network configuration on the host, so if the user has modified the network configuration manually, not via the engine, he should either use the 'refresh capabilities' on engine to reload the new network configuration from the host or to activate the host if it isn't up (which basically calls 'getVdsCapabilities' as well).

If the user decides to change the network configuration in a sense that the host becomes non-operational from the engine point-of-view, there shouldn't be a distinction between changes done on ovirt-node to a non ovirt-node.

The engine will specify what changes are required on the ovirt-node, as long as the connectivity wasn't lost.

I'm not sure we need to prevent from the administrator to perform any manual changes on the host. Perhaps the TUI could reflect the networks name by querying vdsm in the same sense as the engine does so the user will be aware which interfaces carries logical networks.

Comment 4 Dan Kenigsberg 2013-10-22 12:46:39 UTC

Fabian, would you explain which network config you have added manually, when you've configured them, and when they have disappeared? Could you specify vdsm.log from that time?

If you define an ovirtmgmt network (or any other network for that matter), Engine is not expected to change your definitions, unless explicitly requested by Engine's user.

Comment 5 Itamar Heim 2014-01-12 08:43:09 UTC

setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.

Comment 6 Dan Kenigsberg 2014-01-16 10:41:40 UTC

Fabian, please reopen if you can provide the needed information.