feature suggestion: initial generation of management network

[Alon Bar-Lev]

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

Thanks,
Alon