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" <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
