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