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