On 03/23/2014 12:49 PM, Eli Mesika wrote:
----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Eli Mesika" <emes...@redhat.com>, engine-devel@ovirt.org
Sent: Sunday, March 23, 2014 12:14:37 PM
Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
decrease DC compatibility...
On 03/23/2014 12:13 PM, Eli Mesika wrote:
So, as far a I understand for resolving this bug the following is OK :
Block downgrading if there are Hosts or Networks (other than the default
management network) or SD in the DC when downgrading.
yes
BTW there is another BZ for decreasing the default cluster version (BZ 1076555)
Should we apply the same here as well ?
yes.
as for hosts, could be limited to hosts supporting the cluster level
----- Original Message -----
From: "Livnat Peer" <lp...@redhat.com>
To: "Moti Asayag" <masa...@redhat.com>
Cc: engine-devel@ovirt.org
Sent: Friday, March 21, 2014 8:33:59 AM
Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
to decrease DC compatibility...
On 03/20/2014 09:20 PM, Moti Asayag wrote:
----- Original Message -----
From: "Moti Asayag" <masa...@redhat.com>
To: "Livnat Peer" <lp...@redhat.com>
Cc: "Itamar Heim" <ih...@redhat.com>, engine-devel@ovirt.org
Sent: Wednesday, March 12, 2014 10:44:07 PM
Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
to decrease DC compatibility...
----- Original Message -----
From: "Livnat Peer" <lp...@redhat.com>
To: "Moti Asayag" <masa...@redhat.com>
Cc: "Itamar Heim" <ih...@redhat.com>, engine-devel@ovirt.org
Sent: Wednesday, March 12, 2014 10:33:45 PM
Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
enable
to
decrease DC compatibility...
On 03/12/2014 10:20 PM, Moti Asayag wrote:
----- Original Message -----
From: "Livnat Peer" <lp...@redhat.com>
To: "Itamar Heim" <ih...@redhat.com>, engine-devel@ovirt.org
Sent: Wednesday, March 12, 2014 12:42:44 PM
Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
enable
to decrease DC compatibility...
On 03/12/2014 11:59 AM, Itamar Heim wrote:
On 03/12/2014 12:26 AM, emes...@redhat.com wrote:
Eli Mesika has submitted this change and it was merged.
Change subject: core: enable to decrease DC compatibility...
......................................................................
core: enable to decrease DC compatibility...
enable to decrease DC compatibility version if DC has no clusters
This patch enables to decrease the DC compatibility version if DC
has
no
clusters.
Eli - just saw this. I'm pretty sure it would be *bad* to downgrade
a
DC
version if it has storage domains as well. not sure if this is
checked
already or not.
may also be an issue with some logical network features.
Most of the network features are driven from cluster level, we enable
using the features on all DC level (actually >=3.1) but actually
enable
/disable the feature when attaching the network to a cluster.
So from network perspective I think it should be fine to downgrade
the
DC level even if there are networks in the DC (at least now this
could
change in future versions).
Actually we block adding or updating networks if the feature is not
supported
on the network's DC level, for example: STP, Jumbo frames and non-vm
network.
From which DC level we support STP? Jumbo frames? non-vm network?
isn't
all of them supported in >=3.1 ?
Yes, mainly the problem with downgrading a DC to 3.0.
I had a discussion with Mike (cc'ed) about several possible solutions
for the networks compatibility within the data-center.
The first proposed solution would utilize the NetworkUpdateValidator,
a validation utility that verifies the compatibility of a network
to the data-center. This solution preserves the same behaviour as today,
that the features of network-level are dictated by the DC version. No
need to reimplement any logic in the decrease DC version flow, just use
an existing one to be applied for any network within the DC.
The second solution suggests we allow any settings of a network, and
compatibility enforcement is done on attaching the network to the
clusters.
This modifies the existing behaviour and expands the capabilities of the
engine to support advanced network feature in advanced cluster within an
old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
should use non-vm network, jumbo-frames and more).
This option requires more work in add/update network and attach network
to
cluster
flows, both on the backend and UI. Specifically since by default a new
network
created in a DC is being attached to all of the clusters.
Perhaps the second option deserves to be treated as RFE and not as a bug
fix.
Thoughts ?
The second approach you suggested is equivalent to creating networks in
cluster level vs. DC level, which is used today.
We should consider that for 4.0 and think on the pros and cons of doing
so.
In general for this specific discussion I think a simple block on DC
downgrade should be enough.
Moti
Therefore if the management network was configured with any of those
feature,
there is a need to either block the action or to 'initialize' the
network
to
the default settings (as new network being added).
In general I believe the use case for this patch is mostly for empty
DCs
so for simplicity we should block it if there are networks or SD in
the
DC when downgrading.
Livnat
Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
Signed-off-by: Eli Mesika <emes...@redhat.com>
---
M
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
1 file changed, 5 insertions(+), 2 deletions(-)
Approvals:
Eli Mesika: Verified
Ravi Nori: Looks good to me, but someone else must approve
Yair Zaslavsky: Looks good to me, approved
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
