On 05/20/2013 10:18 PM, Alon Bar-Lev wrote: > > > ----- 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.
we don't have the setup network API in 3.0 > > 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? I value the fact that you want to clean the host-deploy code so much but I believe that adding a code that is handling a deprecate state to the engine or VDSM is not in the best interest of our project. > > Regards, > Alon > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
