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

Livnat Peer lpeer at redhat.com
Thu Apr 3 08:20:58 UTC 2014 

On 04/02/2014 09:06 AM, Moti Asayag wrote:
> 
> 
> ----- 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.
> 

Eli -
please note there is no need to block the DC downgrade if there are
hosts in the DC.

Thanks, Livnat


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