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

Sun Mar 23 10:13:26 UTC 2014

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