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