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: "Itamar Heim" <iheim at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 21, 2013 9:58:33 AM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On 05/20/2013 10:18 PM, 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.
> >>>
> >>>> 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

But we do have delNetwork of vdsm?

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

This is not the intention, you are completely wrong.
As I wrote, host-deploy *WILL NOT* remove bridge if it does not need to create any, so currently we broke node support.
Either we handle the bridge at host-deploy or not, what you suggesting is hybrid solution, in which, once again, we duplicate logic between components.
I will release a new minor of ovirt-host-deploy to manage that, as I understand where it is heading.

Thanks,
Alon