Description of problem: adding a newly installed host configured with static IP fails to configure management network on the host. Version-Release number of selected component (if applicable): Fedora 19, ovirt-engine 3.3 nightly - git0c5620a, adding to 3.3 cluster host deploy exits with success. I'll attach ifcfg* to the bug.
Created attachment 777681 [details] ifcfg-em1 before adding the host
Created attachment 777682 [details] ifcfg-em1 after adding the host
Created attachment 777683 [details] ifcfg-ovirtmgmt created after adding the host
from the original ifcfg-em1: ====================== IPADDR0=192.168.1.107 PREFIX0=24 GATEWAY0=192.168.1.1 Are these trailing 0s conventional? Is it a new anaconda behavior? I suspect that vdsm does not parse them, and not expose them properly to Engine. Vdsm should better treat them as their zero-less form (just as initscripts does?)
(In reply to Dan Kenigsberg from comment #4) > Are these trailing 0s conventional? Is it a new anaconda behavior? Not sure if the trailing 0s are from anaconda or from gnome network configuration app. However they come from system configuration tools so we can expect to find them quite often.
In a (late) second thought, I think that it would be much nicer to solve this on the Engine side. Engine should avoid relying on the 'cfg' parameter of network devices, as 'cfg' utterly breaks the Vdsm abstraction and does not fit into where Vdsm wants to go (non-ifcfg netconf). IPADDR and GATEWAY should be take from the network's 'addr' and 'gateway' attributes. If I am not mistaken at the moment, the only need for 'cfg' is BOOTPROTO and BONDING_OPTS. Can we make everything else go?
(In reply to Dan Kenigsberg from comment #7) > In a (late) second thought, I think that it would be much nicer to solve > this on the Engine side. Engine should avoid relying on the 'cfg' parameter > of network devices, as 'cfg' utterly breaks the Vdsm abstraction and does > not fit into where Vdsm wants to go (non-ifcfg netconf). > > IPADDR and GATEWAY should be take from the network's 'addr' and 'gateway' > attributes. If I am not mistaken at the moment, the only need for 'cfg' is > BOOTPROTO and BONDING_OPTS. Can we make everything else go? When you're adding a new host, there are no records on it for in the 'networks' element. Therefore we should rely on some other attribute which could provide the engine the ip address and the gateway of the specific interface. Perhaps we'd like to extend the api of the last_client_iface to provide these values so they won't be tied to a specific implementation.
Oh. 'addr' is already reported per device, however 'gateway' is only a network property. Vdsm would have to report 'gateway' and 'bootproto' per device in order for Engine to drop the 'cfg' dependency.
Does this also affect EL 6 based Hosts? Does this just affect the minimal node iso or also the "full blown host" install?
http://gerrit.ovirt.org/23329/ does not add a new 'gateway' attribute. It only translates GATEWAY0 to GATEWAY, and keeps the ifcfg dependency.
This should be fixed in 3.4.0 beta1
verified oVirt Engine Version: 3.4.0-0.7.beta2.el6
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released