[Engine-devel] network features review

Tue May 22 12:06:56 UTC 2012

On 22/05/12 14:35, avi tal wrote:
> On 05/22/2012 11:45 AM, Livnat Peer wrote:
>> Hi All,
>>
>> This is a summary of comments we(*) gathered while reviewing the current
>> network related functionality in oVirt, we'll open the relevant RFE/Bugs
>> but wanted to share first to get comments:
>>
>>
>> Default Gateway:
>> ----------------
>> current status -
>>    In the UI/API we expose to the user the possibility to configure the
>>    default gateway for the host. We expose this option only when editing
>>    the management network.
>>
>> comments -
>> Apparently we do not configure the host default gateway but the
>> network gateway.
>>
>> 1. We need to fix the phrasing to gateway (not default gateway)
> not true. especially in linux we configure "default gateway". unlike
> windows which holds gateway for each interface, linux holds only one
> default gateway.

I'll leave this one to Danken.

>> 2. Why do we block it for networks which are not the management network
> because otherwise will have to hold the rhevm in the same network with
> the hosts.
> only rhevm bridge is protected from remove and if we'll have gateway
> configured under other network, removing the network will cause losing
> of our connectivity to the host (in case rhevm and host are in different
> networks).
>> 3. We need to support configuring the host default gateway.
> ^^ 1.
>>
>>
>> Non VM (Bridge-less) Network:
>> -----------------------------
>> current status -
>> During bootstrap we configure the management network on the host. We did
>> not implement configuring bridge-less management network during
>> bootstrap.
>>
>> comments -
>> 1. Supporting bridge-less network is a new feature,the design of this
>> feature did not include changing the bootstrap process which make this
>> feature non-useful when it comes to management network.
>>
>> Today one can edit a network only when it is not attached to clusters,
>> at this point you can change the management network to be non-VM
>> network, the problem is that we configure the management network on the
>> host during bootstrap and we do not get a parameter if to create a
>> bridge or not (we always create a bridge).
>>
>> What we end up with is - we can't change the management network once we
>> added clusters/hosts but if changing it before attaching a cluster we
>> ignore it in the bootstrap process.
> Agree, actually bootstrap should configure rhevm network as bridgeless
> network by default.
> We should be able to convert rhevm to bridged network after installVds.
>>
>>
>> Check connectivity:
>> --------------------
>> current status -
>> The 'check connectivity' functionality is available only when editing
>> the management network, it validates that we did not loose connectivity
>> to the host, if we did the changes are rolled backed automatically.
>>
>> comments -
>> 1. Sometimes when changing configuration of another network we can
>> 'damage' the connectivity to the host. We want to expose the check
>> connectivity functionality on any network configuration change.
> I believe we should think about the entire check connectivity mechanism.
> Check connectivity shouldn't rely on the UI check box, it should also
> run automatically in some cases:

It should not run automatically because what it does is not only check
connectivity but also rolls back changes if we loose connectivity.

Let's assume the administrator would like to move the management from
one network to another, he is doing the configuration through RHEVM,
looses connectivity and then goes and physically changes the cables.

In the above case it is ok to loose connectivity and I don't want my
changes to roll back.

> 1. edit mgmt network
> 2. edit other network gateway (if we'll be allowed).
> 3. MUST, when configuring DHCP on different networks.
> 4. when running SetupNetwork. because it forces the user to send the
> management network every time he'd like to update the network.
> 5. remove network. we should be able to check route table before
> removing network and if the specific network holds the GATEWAY we should
> run check connectivity, not before we alert the user.
> 
> In general, gateway should always be monitored by engine and store in
> DB: which interface holds the gateway etc'.
> When we'll be able to do so, we should manage this network (that holds
> the GW) as a "protected network".
> And also expose it to the UI.
>>
>> VLAN tagging of management Network
>> -----------------------------------
>>
>> current status -
>> The user can set a VLAN tag on the management network.
>>
>> comments -
>> 1. Any configuration of the management network needs support in the
>> bootstrap process (see explanation above for bridge-less network)
>> 2. In case of VLAN tagging it is even more complicated, when adding a
>> host to oVirt we add it's address and it can not be changed after the
>> host was added to the system. in the bootstrap process we set the
>> management network on the nic oVirt engine used to ssh through, unless
>> the VLAN device is already configured and the IP used for the ssh is
>> already on this VLAN (for which it will work) we can't set the network
>> to be on another IP address.
>>
>> Rollback network configuration:
>> --------------------------------
>> current status -
>>   We have the option to make changes to the host network configuration
>> and not persist the changes (they won't survive machine reboot)
>>
>> comments -
>> 1. We are missing the functionality of rolling back the changes (without
>> rebooting the machine), this functionality is the complementary behavior
>> of 'save network configuration'.
>>
>>
>> Predefined bonds:
>> -----------------
>> current status -
>> In the bootstrap process we create bonds0-5 on the hosts and then
>> we use them when creating a bond on the host
>>
>> comments -
>> 1. Creating the bonds in the host during the bootstrap process is not
>> needed and we can let the user choose the bond name (limited to bondX)
>> and create bonds only upon request.
>>
>>
>> Editing Network properties while Network is attached to cluster/s
>> ------------------------------------------------------------------
>> current status -
>> Changing the network properties is blocked if the network is attached to
>> a cluster.
>>
>> comments -
>> 1. We should relax this approach. to start with we can enable editing
>> when there are no active hosts in the cluster/s.
>>
>> doing more than the above requires substantially more work both in VDSM
>> and engine.
>>
>>
>>
>> Thank you, Livnat
>>
>>
>> (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti Asayag,
>> Muli Salem, Alona Kaplan, Livnat Peer}
>>
>> (**) We have even longer list for the UI changes needed, for them we'll
>> open bugs directly to avoid another long email.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 