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