feature suggestion: initial generation of management network

[Livnat Peer]

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

> 
> 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
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
>