5:50 p.m.
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)
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
wiki will be updated accordingly.
Thanks,
Roy
9:59 p.m.
On 15/02/12 18:50, 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)
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
I think it is worth mentioning that mixed meaning mix within a cluster
(not DC).
wiki will be updated accordingly.
Thanks,
Roy
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:21 p.m.
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).
(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?
i.e., wouldn't this be interesting per host, that a network which could
be bridgeless is bridged to warn about?
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?
Thanks,
Roy
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:48 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Roy Golan" <rgolan(a)redhat.com>
Cc: engine-devel(a)ovirt.org
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 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?
>
> 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
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
10:35 a.m.
----- Original Message -----
From: "Roy Golan" <rgolan(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, February 16, 2012 10:48:08 AM
Subject: Re: [Engine-devel] bridgeless networks - update
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Roy Golan" <rgolan(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> 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
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:16 a.m.
On 02/16/2012 11:35 AM, Oved Ourfalli wrote:
...
>> 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.
I thought it was supposed to be per cluster (in the grand scheme of
things, as part of also defining what would be the live migration
networks, and things like that - all cluster level definitions).
btw, I may have missed the email on this change, but the wiki doesn't
reflect it at all.
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.
1:20 a.m.
On 02/16/2012 10:48 AM, Roy Golan wrote:
...
> 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...
it is not a question of like/dislike - are you proposing we break the
api for existing users since we don't want to choose a default value for
them?
> (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
if logical network doesn't need to run VMs, if it is bridged on some
hosts, doesn't mean there is an issue.
if logical network is supposed to run VMs, either the network or the
hosts would have it as non operational until the issue is fixed.
how is that different from other network mis configurations?
> i.e., wouldn't this be interesting per host, that a network
which
> could
> be bridgeless 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?
what do you mean by nic type?
4455
days inactive
4457
days old
6 comments
4 participants
participants (4)
-
Itamar Heim -
Livnat Peer -
Oved Ourfalli -
Roy Golan