[Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

Sun Mar 23 10:49:41 UTC 2014

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>, engine-devel at 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" <lpeer at redhat.com>
> >> To: "Moti Asayag" <masayag at redhat.com>
> >> Cc: engine-devel at 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" <masayag at redhat.com>
> >>>> To: "Livnat Peer" <lpeer at redhat.com>
> >>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at 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" <lpeer at redhat.com>
> >>>>> To: "Moti Asayag" <masayag at redhat.com>
> >>>>> Cc: "Itamar Heim" <iheim at redhat.com>, engine-devel at 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" <lpeer at redhat.com>
> >>>>>>> To: "Itamar Heim" <iheim at redhat.com>, engine-devel at 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, emesika at 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 <emesika at 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 at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 