On 04/02/2014 09:06 AM, Moti Asayag wrote: > > > ----- Original Message ----- >> From: "Eli Mesika" <emes...@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" <masa...@redhat.com> >>> To: "Itamar Heim" <ih...@redhat.com> >>> Cc: "Eli Mesika" <emes...@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" <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 >>>> >>> >>> 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. >
Eli - please note there is no need to block the DC downgrade if there are hosts in the DC. Thanks, Livnat >> >>> >>>>> >>>>> >>>>> ----- 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 >>>> >>> >> _______________________________________________ >> 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