feature suggestion: initial generation of management network

Simon Grinberg sgrinber at redhat.com
Mon May 20 12:28:12 UTC 2013 


----- 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. But I think to avoid confusion it needs another thread now the the previous has converged. 

> 
> 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