On Thu 15 Dec 2011 12:05:49 PM IST, Itamar Heim wrote:
On 12/06/2011 11:52 AM, Roy Golan wrote:
> On Tue 06 Dec 2011 11:08:41 AM IST, Roy Golan wrote:
>>
http://www.ovirt.org/wiki/Features/Design/Network
> Hi all,
> The link above is for the wiki describing changes/additions to network
> features for
> the coming future. Network management by the engine is fairly big issue
> and only
> starting to evolve and may take totally different approach in the
> future, so this is a (small) start.
>
> The changes are typically extending the API to be more robust by
> provision a desired network
> topology in one call and create bridge-less networks to utilize network
> more wisely.
how is this feature related to data center compatibility level that it
requires it to be 3.1?
I'd even say this feature is limited to host level of 3.1, not cluster
level?
the only item which would be a DC level is changing MTU, since it
should affect all hosts in the DC using that logical network.
as for MTU max value - I agree we need to check if there is a way to
validate it across all hosts, but I'm pretty sure a config based
validation for min/max mtu sizes is needed.
then a host could fail the change if the MTU isn't supported by it.
so
interface MTU validation should be what? mtu < =1500 && mtu <=
logicalNetwork.mtu?
while MTU is relevant in this verb to setup networks, the change of
the MTU itself as at logical network at DC level, so it needs a flow
for handling a change across all hosts?
probably but just for hosts which are in
maintnace? what about active
one?
maybe put a "pending action for maintenance" note in the gui to inform
some configuration sync is needed.(not sure its the best)
It can fall to in "cluster/dc configuration" case where all cluster
host's should have central configuration and once pulled the
vdsm can care to update its internal accordingly.