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

Moti Asayag masayag at redhat.com
Wed Mar 12 20:44:07 UTC 2014



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

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



More information about the Devel mailing list