On 05/21/2013 06:35 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Dan Kenigsberg" <[email protected]> To: "Alon Bar-Lev"
<[email protected]>, "Mike Burns" <[email protected]> Cc: "Itamar
Heim" <[email protected]>, "arch" <[email protected]> Sent: Tuesday,
May 21, 2013 12:47:04 PM Subject: Re: feature suggestion: initial
generation of management network
On Tue, May 21, 2013 at 12:09:19PM +0300, Dan Kenigsberg wrote:
On Mon, May 20, 2013 at 03:18:52PM -0400, 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.
Indeed. And for this reason, ovirt-node should avoid creating
these brXXX bridges when ovirt-node-plugin-vdsm is installed.
Obviously, this can be done only from 3.3 and forward.
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?
The bootstrap-time setupNetwork has to be automatic, of course.
It should create the management network, but should not ruin
pre-existing networks, that might have been defined by an admin
on the host. But we cannot distinguish an ovirt-node automatic
brXXX bridge from a same-named network, intentionally defined
there.
I'm not sure if anyone is using or expecting these breth*
bridges. In the vdsm/engine context, they are no more than
nuisance. Someone once told me that such nuisance should be
removed at the nearest point possible, and luckily, we already
have the code to do this in ovirt-host-deploy.
So I'm voting for (3): if ovirt-host-deploy does not receive
VDSM/managementBridgeName, it should still remove the brXXX
bridges.
arghh, obviously, I was voting for (1), and obviously, there were
other messages in this thread while I was writing mine.
Regardless the implications made earlier, the mission is not
originated in cleaning up the code, but reduce the risk of breakage
during host-deploy.
Although we managed to reduce the risk of breakage when using
standard host, we fail to do so using ovirt-node if we require to
delete a bridge:
1. We continue to guess the interface used to communicate with engine
by trying to find the best route from the host to vdsm, while
outgoing route may be different than incoming route.
2. We continue to try to initiate outgoing communication from host to
engine in order to find out when interface is up, while there is no
guarantee that we can initiate communication.
3. We keep starting libvirtd, messagebus on host and use delNetwork,
vdsm-store-net-config on nodes.
So unfortunately, I don't see any real value of creating the bridge
at engine when we deal with ovirt-node.
I think the simplest way is to have VdsDeploy (engine side) to set
bridge name if node is detected, so that bridge will be created by
host-deploy using the legacy logic.
Regards, Alon
Catching up on this thread with analysis of impact on ovirt-node.
The request is to not create the bridge by default (or at least provide
a method to disable bridge creation). Having the bridge is a pretty
basic assumption that has always been in ovirt-node. It's not something
we could reliably change in the timeframe of the oVirt 3.3 release.
Beta/Feature Freeze for oVirt 3.3 is 31-May. oVirt Node is already in
RC for our 3.0 release. At best, we could maybe deliver it sometime in
June, but I don't feel it would be stable enough to be used in 3.3 GA.
Note: there are other aspects of this as well. We lock out network
configuration locally based on the existence of the ovirtmgmt bridge, so
we need to add methods to handle that issue as well.
Mike
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
