feature suggestion: initial generation of management network

[Dan Kenigsberg]

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.