feature suggestion: initial generation of management network
Moti Asayag
masayag at redhat.com
Mon May 20 13:01:30 UTC 2013
On 05/20/2013 03:31 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Simon Grinberg" <sgrinber at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "arch" <arch at ovirt.org>, "Moti Asayag" <masayag at redhat.com>
>> Sent: Monday, May 20, 2013 3:28:12 PM
>> Subject: Re: feature suggestion: initial generation of management network
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>
>>> Sent: Monday, May 20, 2013 7:58:05 AM
>>> Subject: Re: feature suggestion: initial generation of management network
>>>
>>> Hi,
>>>
>>> Now another issue... ovirt-node.
>>>
>>> In ovirt-node, the node already defines a bridge which is called
>>> br at INTERFACE@, this is done automatically.
>>> The IP address of ovirt-node is assigned to that bridge, so we always
>>> have a bridge at ovirt-node.
>>>
>>> I have the following useless in my code, most is legacy... the
>>> question...
>>> Can this also be automated by the new code at engine side?
>>> It should or things will break...
>>
>> I don't see why the flows should be kept different - so we should find a way
>> for doing the same with the nodes.
>
> Because as far as I know in current implementation, we did not take the ovirt-node specific behavior into account, right Moti?
Correct. See Livnat reply.
>
>> But I think to avoid confusion it needs
>> another thread now the the previous has converged.
>
> I removed all other people from the CC...
>
>>
>>>
>>> Thanks,
>>> Alon
>>>
>>> ---
>>>
>>> if (
>>> self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and
>>> self._interfaceIsBridge(name=interface)
>>> ):
>>> nic = interface.replace('br', '', 1)
>>> self._removeBridge(
>>> name=interface,
>>> interface=nic,
>>> )
>>> interface = nic
>>>
>>>
>>> def _removeBridge(self, name, interface):
>>> interface, vlanid = self._getVlanMasterDevice(name=interface)
>>> self.execute(
>>> (
>>> os.path.join(
>>> odeploycons.FileLocations.VDSM_DATA_DIR,
>>> 'delNetwork',
>>> ),
>>> name,
>>> vlanid if vlanid is not None else '',
>>> '', # bonding is not supported
>>> interface if interface is not None else '',
>>> ),
>>> )
>>>
>>> #
>>> # vdsm interface does not handle
>>> # ovirt node properly.
>>> # we should manually delete the
>>> # ifcfg file to avoid having duplicate
>>> # bridge.
>>> #
>>> if self.environment[odeploycons.VdsmEnv.OVIRT_NODE]:
>>> ifcfg = '/etc/sysconfig/network-scripts/ifcfg-%s' % (
>>> name
>>> )
>>> if os.path.exists(ifcfg):
>>> from ovirtnode import ovirtfunctions
>>> ovirtfunctions.ovirt_safe_delete_config(ifcfg)
>>>
>>> ----- Original Message -----
>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>> Cc: "arch" <arch at ovirt.org>, alonbl at redhat.com, "Simon Grinberg"
>>>> <sgrinber at redhat.com>, "Andrew Cathrow"
>>>> <acathrow at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Barak
>>>> Azulay" <bazulay at redhat.com>
>>>> Sent: Monday, May 20, 2013 2:49:18 PM
>>>> Subject: Re: feature suggestion: initial generation of management
>>>> network
>>>>
>>>> This is a summary of the thread so far (and the AI)-
>>>>
>>>> - There is an agreement we do not need machine boot in the
>>>> installation
>>>> sequence.
>>>>
>>>> - The current default behavior is to reboot after host installation
>>>> (in
>>>> Virt)
>>>>
>>>> ** We are going to change current behavior in 3.3 and remove the
>>>> reboot
>>>> from the host installation flow **
>>>>
>>>> - Today we have a flag in the REST API to avoid host reboot,we'll
>>>> deprecate this flag since this is going to be the default behavior
>>>> after
>>>> the change (and booting after installation won't be available).
>>>>
>>>> - Since host reboot is not needed in the host install flow we avoid
>>>> adding VDSM verb for reboot at this point. The discussion if to do
>>>> such
>>>> a verb via ssh or VDSM can be done in the context were the verb is
>>>> going
>>>> to be used.
>>>>
>>>>
>>>> Thanks, Livnat
>>>>
>>>>
>>>>
>>>>
>>>> On 12/25/2012 02:27 PM, Dan Kenigsberg wrote:
>>>>> Current condition:
>>>>> ==================
>>>>> The management network, named ovirtmgmt, is created during host
>>>>> bootstrap. It consists of a bridge device, connected to the
>>>>> network
>>>>> device that was used to communicate with Engine (nic, bonding or
>>>>> vlan).
>>>>> It inherits its ip settings from the latter device.
>>>>>
>>>>> Why Is the Management Network Needed?
>>>>> =====================================
>>>>> Understandably, some may ask why do we need to have a management
>>>>> network - why having a host with IPv4 configured on it is not
>>>>> enough.
>>>>> The answer is twofold:
>>>>> 1. In oVirt, a network is an abstraction of the resources
>>>>> required for
>>>>> connectivity of a host for a specific usage. This is true for
>>>>> the
>>>>> management network just as it is for VM network or a display
>>>>> network.
>>>>> The network entity is the key for adding/changing nics and IP
>>>>> address.
>>>>> 2. In many occasions (such as small setups) the management
>>>>> network is
>>>>> used as a VM/display network as well.
>>>>>
>>>>> Problems in current connectivity:
>>>>> ================================
>>>>> According to alonbl of ovirt-host-deploy fame, and with no
>>>>> conflict to
>>>>> my own experience, creating the management network is the most
>>>>> fragile,
>>>>> error-prone step of bootstrap.
>>>>>
>>>>> Currently it always creates a bridged network (even if the DC
>>>>> requires a
>>>>> non-bridged ovirtmgmt), it knows nothing about the defined MTU
>>>>> for
>>>>> ovirtmgmt, it uses ping to guess on top of which device to build
>>>>> (and
>>>>> thus requires Vdsm-to-Engine reverse connectivity), and is the
>>>>> sole
>>>>> remaining user of the addNetwork/vdsm-store-net-conf scripts.
>>>>>
>>>>> Suggested feature:
>>>>> ==================
>>>>> Bootstrap would avoid creating a management network. Instead,
>>>>> after
>>>>> bootstrapping a host, Engine would send a getVdsCaps probe to the
>>>>> installed host, receiving a complete picture of the network
>>>>> configuration on the host. Among this picture is the device that
>>>>> holds
>>>>> the host's management IP address.
>>>>>
>>>>> Engine would send setupNetwork command to generate ovirtmgmt with
>>>>> details devised from this picture, and according to the DC
>>>>> definition of
>>>>> ovirtmgmt. For example, if Vdsm reports:
>>>>>
>>>>> - vlan bond4.3000 has the host's IP, configured to use dhcp.
>>>>> - bond4 is comprises eth2 and eth3
>>>>> - ovirtmgmt is defined as a VM network with MTU 9000
>>>>>
>>>>> then Engine sends the likes of:
>>>>> setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>>>>> bonding=bond4: {eth2,eth3}, MTU=9000)
>>>>>
>>>>> A call to setSafeNetConfig would wrap the network configuration
>>>>> up.
>>>>>
>>>>> Currently, the host underegoes a reboot as the last step of
>>>>> bootstrap.
>>>>> This allows us to verify immediately if the host would be
>>>>> accessible
>>>>> post-boot using its new network configuration. If we want to
>>>>> maintain
>>>>> this, Engine would need to send a fenceNode request.
>>>>>
>>>>> Benefits:
>>>>> =========
>>>>> - Simplified bootstrapping
>>>>> - Simplified ovirt-node registration (similar
>>>>> ovirtmgmt-generation logic
>>>>> lies there).
>>>>> - Host installation ends with an ovirtmgmt network that matches
>>>>> DC
>>>>> definition (bridged-ness, mtu, vlan).
>>>>> - vdsm-to-engine connectivity is not required.
>>>>>
>>>>> Drawbacks:
>>>>> ==========
>>>>> - We need to implement new Engine logic for devising ovirtmgmt
>>>>> definition
>>>>> out of
>>>>> getVdsCaps output.
>>>>> - ... your input is welcome here
>>>>>
>>>>> Missing:
>>>>> ========
>>>>> A wiki feature page for this new behavior.
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
More information about the Arch
mailing list