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