[Users] affects of changing compatibility setting on running cluster

[Itamar Heim]

On 03/13/2014 05:33 PM, Charles Weber wrote:
>
> On Mar 12, 2014, at 5:14 PM, Itamar Heim <iheim at redhat.com
> <mailto:iheim at redhat.com>> wrote:
>
>> On 03/12/2014 10:45 PM, ybronhei wrote:
>>> On 03/12/2014 04:33 PM, Itamar Heim wrote:
>>>> On 03/12/2014 04:32 PM, ybronhei wrote:
>>>>> On 03/12/2014 04:25 PM, Dan Kenigsberg wrote:
>>>>>> On Wed, Mar 12, 2014 at 10:15:21AM +0200, Itamar Heim wrote:
>>>>>>> On 03/12/2014 10:11 AM, Sven Kieske wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 11.03.2014 17:38, schrieb Itamar Heim:
>>>>>>>>>
>>>>>>>>> i understood this to "you can't use 4.14 with 3.4.0".
>>>>>>>>
>>>>>>>> Well I examined BZ 1067096 again, this is what did not work:
>>>>>>>>
>>>>>>>> Steps to Reproduce:
>>>>>>>> 1.  Run Engine 3.3 Compatibility level 3.2 or 3.3
>>>>>>>> 2.  Add node (vdsm 4.14)
>>>>>>>>
>>>>>>>> Actual results:
>>>>>>>> Host is installed with VDSM version (4.14) and cannot join cluster
>>>>>>>> which
>>>>>>>> is compatible with VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10].
>>>>>>>>
>>>>>>>> Pay attention to the engine version, it states 3.3. not 3.4.0
>>>>>>>>
>>>>>>>> So my conclusion is, you can't install vdsm 4.14. when you want
>>>>>>>> to use engine 3.3.
>>>>>>>>
>>>>>>>> Am I reading something wrong?
>>>>>>>>
>>>>>>>> Here's the link again:
>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1067096#c0
>>>>>>>>
>>>>>>>
>>>>>>> this can be fixed via engine config, but is not supposed to be
>>>>>>> needed, as vdsm is supposed to have
>>>>>>> vdsm/dsaversion.py.in:    'supportedENGINEs': ['3.0', '3.1', '3.2',
>>>>>>> '3.3', '3.4'],
>>>>>>>
>>>>>>> danken/eli - thoughts?
>>>>>>
>>>>>> I do not really understand why we have this recurrent Engine bug, of
>>>>>> ignoring supportedENGINEs; I think Yaniv does.
>>>>>>
>>>>>
>>>>> i recall asking for detailed explanation for why do we have 3 different
>>>>> restrictions , one for supportedEngines, one for the allowed vdsm
>>>>> versions, and one for the cluster level?
>>>>>
>>>>> if vdsm version is supported why isn't it in engine's capabilities yet?
>>>>
>>>> because its a vdsm version which was released after that engine was
>>>> released, hence the vdsm package has to declare its supporting the old
>>>> engine.
>>>>
>>>
>>> so its an hack to allow users to add beta vdsm version to new engine
>>> release?.. sounds like that
>>
>> no. its to add the next release of vdsm to a previously released
>> engine. but that's not supposed to be an issue, since its supposed to
>> already report the previous version of engine (which it does)
>>
>>>
>>> please reopen if it reproduced
>>>
>>>>>
>>>>> the issue was verified in
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1016461, please reopen if
>>>>> it still appears
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
> I do have an issue still with this.
> When I try to change compatibility version at the datacenter level it
> behaves as expected, i.e. warns me to change the cluster level first. I
> see a matching log entry in the engine log. However when I try to change
> the compatibility version at the cluster level the edit cluster dialog
> box just hangs there. There are no log entries in the engine log. The
> dialog box goes away when I click cancel. If I select 3.2 or 3.3 and
> click OK nothing happens. This occurs either during normal running or
> with hosts in maintenance mode.
>
> I would like to change to 3.3. Can you direct me to the sql table or cmd
> line by any chance.

do not hack the db for such a change, you may skip important upgrade 
logic/validation.

>
> Is this a known problem or something specific to my special setup.
>   Actually my setup is pretty plain, see below or original post in this
> thread.

sounds like a bug, at least for not telling you what is the error.
omer - thoughts?

>
> Engine 3.3.4-1.el6
> CO6.5
> Nodes are 3.0.4-1.0.201401291204.el6
> Storage is SAN
>
>