feature suggestion: initial generation of management network
Livnat Peer
lpeer at redhat.com
Tue May 21 06:55:13 UTC 2013
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.
>
We want to discuss the bridge creation with Mike to see if it still
makes sense.
If it does we though to remove the bridges in the ovirt-node-plugin-vdsm
(which is a node code not VDSM's).
>> 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.
We can use it in 3.2 and 3.1 where we have sync network, a user would
need to sync network (which will remove the bridge).
> 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.
We don't need this info.
If the bridge is there we need to run the code we have today if there is
no bridge there is nothing to do during host-deploy.
At the phase of the management bridge configuration in the engine we
detect if there is a bridge or not if there is one we don't touch the
configuration if there is none we create one (or not according to the
network definition).
>
> 2. I release a new minor version of ovirt-host-deploy that delete the bridge regardless of the mode.
>
That is not good as we don't have setup-network in 3.0.
> 3. Engine will be able to delete this bridge just like he is able to create the management bridge.
>
- I don't like this as this means we need to write code for deprecated
state, we already have code for handling this today it is in the host
deploy.
- it is not a valid solution as we can't handle v 3.0
>> 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.
>
> Thanks,
> Alon
>
More information about the Arch
mailing list