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

Moti Asayag masayag at redhat.com
Wed Apr 2 06:06:21 UTC 2014 


----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: engine-devel at 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" <masayag at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "Eli Mesika" <emesika at redhat.com>, engine-devel at 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" <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
> > > 
> > 
> > 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" <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
> > > >
> > > 
> > > _______________________________________________
> > > 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
>

More information about the Engine-devel mailing list