[Engine-devel] Network features design wiki

[Miki Kenneth]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Roy Golan" <rgolan at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, December 15, 2011 1:44:07 PM
> Subject: Re: [Engine-devel] Network features design wiki
> 
> On 12/15/2011 01:03 PM, Roy Golan wrote:
> > 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.
> 
> for first phase - probably just block change of an MTU if there is
> any
> host in UP status in the DC.
Grrrr, but I guess ok for first version (only) !
> also, since users may have changed the MTU at host level, need to
> make
> sure to not override it unless user explicitly asked to set the MTU.
> also worth checking what exactly is the default MTU for a host today
> (1500) and warn if it is different than the "default unconfigured
> MTU"
> and recommend they set the MTU correctly.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>