feature suggestion: initial generation of management network

[Alon Bar-Lev]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Mike Burns" <mburns at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 21, 2013 12:47:04 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On Tue, May 21, 2013 at 12:09:19PM +0300, Dan Kenigsberg wrote:
> > On Mon, May 20, 2013 at 03:18:52PM -0400, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <iheim at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Livnat Peer" <lpeer at redhat.com>, "arch" <arch at ovirt.org>, "Mike
> > > > Burns" <mburns at redhat.com>
> > > > Sent: Monday, May 20, 2013 10:10:20 PM
> > > > Subject: Re: feature suggestion: initial generation of management
> > > > network
> > > > 
> > > > On 05/20/2013 04:08 PM, Alon Bar-Lev wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Livnat Peer" <lpeer at redhat.com>
> > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >> Cc: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
> > > > >> Sent: Monday, May 20, 2013 3:55:42 PM
> > > > >> Subject: Re: feature suggestion: initial generation of management
> > > > >> network
> > > > >>
> > > > >> On 05/20/2013 02:58 PM, Alon Bar-Lev wrote:
> > > > >>> 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...
> > > > >>>
> > > > >>
> > > > >> For ovirt node -
> > > > >>
> > > > >> For images 3.3 and above the code below can be removed, we will make
> > > > >> shore that the ovirt-node-plugin-vdsm would not create the brXXX
> > > > >> bridges
> > > > >> (or if we have no choice remove them).
> > > > >
> > > > > I thought this is created in the node-core...
> > > > > Just confirmed.
> > > > > A node without vdsm plugin also create that bridge.
> > > > > vdsm has nothing to do with this process as far as I know.
> > 
> > Indeed. And for this reason, ovirt-node should avoid creating these
> > brXXX bridges when ovirt-node-plugin-vdsm is installed. Obviously, this
> > can be done only from 3.3 and forward.
> > 
> > > > >
> > > > >> For images 3.2 and below we still need this code, because oVirt node
> > > > >> creates brXXX bridges and the engine do not configure the network
> > > > >> automatically if a bridge exists on the interface.
> > > > >
> > > > > It is not just 'need this code' it is that we cannot use the
> > > > > bridgeless
> > > > > solution at enigne.
> > > > > Options:
> > > > >
> > > > > 1. We need to detect node version and perform bridgeless deployment
> > > > > if node
> > > > > is >= x, but we do not know this at engine when we deploy a host...
> > > > > we
> > > > > even do not know that it is ovirt-node.
> > > > >
> > > > > 2. I release a new minor version of ovirt-host-deploy that delete the
> > > > > bridge regardless of the mode.
> > > > >
> > > > > 3. Engine will be able to delete this bridge just like he is able to
> > > > > create
> > > > > the management bridge.
> > > > >
> > > > >> The down side to the above is that for management networks that
> > > > >> configured in the engine as bridgeless the management network on the
> > > > >> host would still be bridged thus will be marked as not-in-sync.
> > > > >
> > > > > Right, and because of that I think that (3) is the best solution.
> > > > 
> > > > adding mike - not sure if this is the solution we prefer, but if we
> > > > don't want the bridge, it should not be there and be part of the
> > > > responsibility of the plugins that do want it.
> > > > 
> > > > at some point we will move to 4.0, deprecating support for things older
> > > > than say 3.4. so that's another way to cleanup old code if we need it
> > > > for backward compatibility in the meantime, flagging it for removal in
> > > > 4.0.
> > > 
> > > I do not understand why it is easy to add a bridge but not remote a
> > > bridge if it is exists.
> > > 
> > > This regardless of the requirement to remove/leave the bridge in
> > > ovirt-node.
> > > 
> > > If the feature exists in both engine and vdsm, and engine can
> > > enumerate bridges why not simply use these feature in order to
> > > provision the existing ovirt-node correctly?
> > 
> > The bootstrap-time setupNetwork has to be automatic, of course.
> > It should create the management network, but should not ruin
> > pre-existing networks, that might have been defined by an admin on the
> > host. But we cannot distinguish an ovirt-node automatic brXXX bridge
> > from a same-named network, intentionally defined there.
> > 
> > I'm not sure if anyone is using or expecting these breth* bridges.
> > In the vdsm/engine context, they are no more than nuisance. Someone once
> > told me that such nuisance should be removed at the nearest point
> > possible, and luckily, we already have the code to do this in
> > ovirt-host-deploy.
> > 
> > So I'm voting for (3): if ovirt-host-deploy does not receive
> > VDSM/managementBridgeName, it should still remove the brXXX bridges.
> 
> arghh, obviously, I was voting for (1), and obviously, there were other
> messages in this thread while I was writing mine.
> 

Regardless the implications made earlier, the mission is not originated in cleaning up the code, but reduce the risk of breakage during host-deploy.

Although we managed to reduce the risk of breakage when using standard host, we fail to do so using ovirt-node if we require to delete a bridge:

1. We continue to guess the interface used to communicate with engine by trying to find the best route from the host to vdsm, while outgoing route may be different than incoming route.

2. We continue to try to initiate outgoing communication from host to engine in order to find out when interface is up, while there is no guarantee that we can initiate communication.

3. We keep starting libvirtd, messagebus on host and use delNetwork, vdsm-store-net-config on nodes.

So unfortunately, I don't see any real value of creating the bridge at engine when we deal with ovirt-node.

I think the simplest way is to have VdsDeploy (engine side) to set bridge name if node is detected, so that bridge will be created by host-deploy using the legacy logic.

Regards,
Alon