----- Original Message ----- > From: "Livnat Peer" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Moti Asayag" <[email protected]>, "arch" <[email protected]> > 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@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 _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
