----- Original Message -----
> From: "Roy Golan" <[email protected]>
> To: "Itamar Heim" <[email protected]>
> Cc: [email protected]
> Sent: Thursday, February 16, 2012 10:48:08 AM
> Subject: Re: [Engine-devel] bridgeless networks - update
>
>
>
> ----- Original Message -----
> > From: "Itamar Heim" <[email protected]>
> > To: "Roy Golan" <[email protected]>
> > Cc: [email protected]
> > Sent: Thursday, February 16, 2012 12:21:49 AM
> > Subject: Re: [Engine-devel] bridgeless networks - update
> >
> > On 02/15/2012 06:50 PM, Roy Golan wrote:
> > > following ovirt engine weekly here's a summary of the changes:
> > >
> > > 1. no validation during vmInterface creation
> > > 2. when attaching a network the default value is bridged (GUI
> > > responsibility)
> >
> > so what is the default if one didn't pass it in the API (i.e.,
> > backend
> > should have a default value. UI may choose whatver).
> I generally dislike default values in API because client
> wont know what it is, default behavior might change in time etc...
> > (and the UI/API name in the wiki is something around "allow to run
> > vms",
> > not bridged - so maybe change the terminology used to discuss this
> > to
> > reduce risk of confusion/mistakes later).
> >
> >
> > > 3. monitoring - detect mixed configured cluster (network "foo" is
> > > bridged on one host and not on another)
> > > and issue an audit log warning with event interval of 1 day
> >
> > why does this matter if cluster is mixed?
> to inform a potential migration problem
> > i.e., wouldn't this be interesting per host, that a network which
> > could
> > be bridgeless http://www.ovirt.org/Features/Design/Network/SetupNetworks/is
> > bridged to warn about?
> I agree that an admin might like a notice that he can improve the
> host's performance.
> but currently how can we say a network can be bridgeless given that
> we don't have the nic type yet?
> detect if no vmInterfaces are connected to it maybe?
>
Itamar - It was decided to remove the "allow to run VMs" attribute on the
logical network level (to simplify things, not sure it is the right way,
though). AFAIU the main reason for that is that we might want to use a network
for VMs in one cluster, and for other uses on another cluster. Not sure how
important this use-case is, but in AFAIU that was the main reason to leave this
attribute aside for now, and add it only later on.
If we indeed don't add this attribute then we can't really tell the admin "this
network can be bridgeless" as we don't know that. Maybe the user wants to run
VMs on it. So, we can just warn him in several scenarios that what he is doing
is probably wrong, or we can monitor that and issue a warning event.
If we do add this attribute then we can decide on a different logic: allowing
only bridge for VM networks, allowing both but warn the user, monitoring for
"mixed" configurations, and etc., according to what we think is a reasonable
use-case.
> >
> > >
> > > wiki will be updated accordingly.
> >
> > having fast read it, couldn't understand the backward compatibility
> > section ("Its compatibility version is 3.1 and enforced by the
> > enclosed
> > command as mentioned already")
> > i'd make it clear this is a 3.1 DC feature, and not a cluster
> > one(?)
> > becuase iirc, setupNetworks is actually host level 3.1
> > compatibility
> > level, not cluster/dc wide?
> yes its not clear enough that 3.0 cluster cannot have their network
> bridgeless. will fix this to be clearer.
> >
> > >
> > > Thanks,
> > > Roy
> > > _______________________________________________
> > > Engine-devel mailing list
> > > [email protected]
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> _______________________________________________
> Engine-devel mailing list
> [email protected]
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
