On 03/12/2014 12:47 PM, Itamar Heim wrote:

On 03/12/2014 12:42 PM, Livnat Peer wrote:

...

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.

other than ovirt/rhevm one of course.

of course, the management network which is automatically created when creating the DC can be there.

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 03/12/2014 10:20 PM, Moti Asayag wrote:

----- Original Message -----

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@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, emesika@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 ?

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 <emesika@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

----- Original Message -----

From: "Moti Asayag" <masayag@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Itamar Heim" <iheim@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, emesika@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 ? 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 <emesika@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

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. ----- Original Message -----

From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@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" <masayag@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Itamar Heim" <iheim@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, emesika@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 <emesika@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

----- Original Message -----

From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@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 ?

...

----- Original Message -----

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@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" <masayag@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> >> To: "Itamar Heim" <iheim@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, emesika@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 <emesika@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

----- Original Message -----

From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@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

I don't think it is enough. There is a need to verify the management network wasn't modified to use unsupported features in the new data-center. On the same matter, we can allow downgrading if all of the networks in the data center are using only features that are supported on the target DC version and not to restrict it only to the management network.

...

----- Original Message -----

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@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" <masayag@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> >> To: "Itamar Heim" <iheim@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, emesika@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 <emesika@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

----- Original Message -----

From: "Eli Mesika" <emesika@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, March 27, 2014 1:43:22 PM Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

----- Original Message -----

...

From: "Moti Asayag" <masayag@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Eli Mesika" <emesika@redhat.com>, engine-devel@ovirt.org Sent: Sunday, March 23, 2014 2:47:53 PM Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

----- Original Message -----

...

From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@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

I don't think it is enough. There is a need to verify the management network wasn't modified to use unsupported features in the new data-center.

On the same matter, we can allow downgrading if all of the networks in the data center are using only features that are supported on the target DC version and not to restrict it only to the management network.

Since Moti is in PTO, talked with Mike K to get advanced with that , we came to the following conclusion:

when DC is downgraded : Block downgrading if there are Hosts or Networks (other than the default management network) or SD in the DC. In case that only default management network exists we should check that all network features are still supported (This can be done by adding a method to the NetworkValidator that will check for support of all relevant features)

when Cluster is downgraded : Same as above , but we don't need to check for features validation since we can not downgrade below the DC version and therefor the cluster network is supposed to be valid already

Mike, please let me know If I miss something from our discussion (and thanks for your kind help :-) )

+1 from me and Mike for the above.

...

...

...

----- Original Message -----

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@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" <masayag@redhat.com> > To: "Livnat Peer" <lpeer@redhat.com> > Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> >> To: "Moti Asayag" <masayag@redhat.com> >> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> >>>> To: "Itamar Heim" <iheim@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, emesika@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 <emesika@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

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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.

Why does having hosts should prevent us from downgrading the DC level?

----- Original Message -----

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Moti Asayag" <masayag@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" <masayag@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: "Itamar Heim" <iheim@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" <lpeer@redhat.com> > To: "Itamar Heim" <iheim@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, emesika@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 <emesika@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

On 03/23/2014 01:10 PM, Itamar Heim wrote:

On 03/23/2014 12:25 PM, Livnat Peer wrote:

...

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.

Why does having hosts should prevent us from downgrading the DC level?

tomorrow you may have hosts which won't support an older cluster.

Host are associated with a cluster, how can downgrading of DC level impact the existing hosts? DC downgrade does not downgrade the clusters level.

On 03/23/2014 01:39 PM, Itamar Heim wrote:

On 03/23/2014 01:13 PM, Livnat Peer wrote:

...

On 03/23/2014 01:10 PM, Itamar Heim wrote:

...

On 03/23/2014 12:25 PM, Livnat Peer wrote:

...

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.

Why does having hosts should prevent us from downgrading the DC level?

tomorrow you may have hosts which won't support an older cluster.

Host are associated with a cluster, how can downgrading of DC level impact the existing hosts? DC downgrade does not downgrade the clusters level.

well, you are kind of explaining why this can't happen... a DC can only be upgraded if all Clusters have already been upgraded. hence a DC can only be downgraded if it has no clusters, hence no hosts. (because to downgrade the DC, the clusters would have to be downgraded first, and you can't have a cluster lower than the DC...)

The only rule we enforce today is - DC level <= Cluster level : for all clusters in the DC Thus you can downgrade the DC with clusters in it with no effect on the clusters or the hosts. The clusters do not need to be downgraded.

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel