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

----- Original Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > To: "Eli Mesika" <emesika(a)redhat.com&gt;, engine-devel(a)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(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 >> > >