Red Hat Bugzilla – Bug 1021649
Keep existing bond and bridge configurations or tell the user that they will be lost
Last modified: 2014-09-24 10:24:56 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
Moti, have no idea what it is about... but should be done post-deploy...
(In reply to Alon Bar-Lev from comment #1)
> Moti, have no idea what it is about... but should be done post-deploy...
so what can I do to make this clearer?
(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...
> 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.
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.
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.
Fabian, please reopen if you can provide the needed information.