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

Sun Mar 23 11:10:46 UTC 2014

On 03/23/2014 12:49 PM, Eli Mesika wrote:
>
>
> ----- 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
>
> BTW there is another BZ for decreasing the default cluster version (BZ 1076555)
> Should we apply the same here as well ?

yes.
as for hosts, could be limited to hosts supporting the cluster 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
>>>
>>
>>