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

Sun Mar 23 10:25:48 UTC 2014

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

Why does having hosts should prevent us from downgrading the DC level?

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