Bug 1021649 - Keep existing bond and bridge configurations or tell the user that they will be lost
Keep existing bond and bridge configurations or tell the user that they will ...
Status: CLOSED INSUFFICIENT_DATA
Product: oVirt
Classification: Community
Component: ovirt-engine-core (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.4.0
Assigned To: Moti Asayag
network
: Triaged
Depends On:
Blocks: 920171
  Show dependency treegraph
 
Reported: 2013-10-21 13:32 EDT by Fabian Deutsch
Modified: 2014-09-24 10:24 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-16 05:41:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2013-10-21 13:32:21 EDT
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 13:55:02 EDT
Moti, have no idea what it is about... but should be done post-deploy...
Comment 2 Fabian Deutsch 2013-10-21 15:27:47 EDT
(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 05:36:33 EDT
(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 08:46:39 EDT
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 03:43:09 EST
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 05:41:40 EST
Fabian, please reopen if you can provide the needed information.

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