Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

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(a)redhat.com&gt; > To: "Moti Asayag" <masayag(a)redhat.com&gt; > Cc: engine-devel(a)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(a)redhat.com&gt; >>> To: "Livnat Peer" <lpeer(a)redhat.com&gt; >>> Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, engine-devel(a)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(a)redhat.com&gt; >>>> To: "Moti Asayag" <masayag(a)redhat.com&gt; >>>> Cc: "Itamar Heim" <iheim(a)redhat.com&gt;, engine-devel(a)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(a)redhat.com&gt; >>>>>> To: "Itamar Heim" <iheim(a)redhat.com&gt;, engine-devel(a)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(a)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(a)redhat.com&gt; >>>>>>>> --- >>>>>>>> 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(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 >> >> > > _______________________________________________ > 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