[Users] affects of changing compatibility setting on running cluster

Charles Weber chaweber at gmail.com
Mon Mar 17 19:44:09 UTC 2014


On Mar 17, 2014, at 4:41 AM, Tomas Jelinek <tjelinek at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
>> Cc: "Charles Weber" <chaweber at gmail.com>, "ybronhei" <ybronhei at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>,
>> users at ovirt.org, "Eli Mesika" <emesika at redhat.com>, "Sven Kieske" <S.Kieske at mittwald.de>
>> Sent: Sunday, March 16, 2014 10:04:12 AM
>> Subject: Re: [Users] affects of changing compatibility setting on running cluster
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Charles Weber" <chaweber at gmail.com>
>>> Cc: "ybronhei" <ybronhei at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>,
>>> users at ovirt.org, "Eli Mesika"
>>> <emesika at redhat.com>, "Sven Kieske" <S.Kieske at mittwald.de>, "Omer Frenkel"
>>> <ofrenkel at redhat.com>
>>> Sent: Friday, March 14, 2014 12:58:57 AM
>>> Subject: Re: [Users] affects of changing compatibility setting on running
>>> cluster
>>> 
>>> 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?
>>> 
>> 
>> if nothing happens when clicking ok it's usually some validation in the
>> dialog,
>> can you check there is nothing highlighted in red (check also other tabs in
>> the dialog)?
> 
> Indeed, can be a validation problem (the better case) or can be an exception on FE (worse case).
> If you verify that there is no validation error on the dialog and the click does not work, could you please have a look at the javascript console on the FE?
> (you can do this in firefox by tools->web developer->web console and on the bottom select JS, simulate the issue and check if there is some exception. If there is, please
> send it and tell me also on what browser have you simulated it in).
> 
> 
>> 
>> adding Tomas, might have a better idea.
>> 
>> you can try updating using rest api (change user/pass and cluster uuid):
>> 
>> curl -X PUT -H "Accept: application/xml" -H "Content-Type: application/xml"
>> -u "admin at internal:password"
>> "http://localhost:8080/api/clusters/dd746d43-4bd1-46aa-b97b-b7bad3f2e498" -d
>> "<cluster><version major=\"3\" minor=\"3\"/></cluster>"
>> 
>> 
>>>> 
>>>> Engine 3.3.4-1.el6
>>>> CO6.5
>>>> Nodes are 3.0.4-1.0.201401291204.el6
>>>> Storage is SAN
1. No red on of the browser window forms when  I try to change from 3.2 to 3.3
2. Used firefox 27.0.1 on Mac to test this now.
3. When I deselect everything but JS on web console I get exactly nothing showing up on the console when I click the OK button. It doesnt matter if I leave the version selector on 3.2 or change to 3.3.
4. I will look at the rest statement.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140317/7aaf53dd/attachment-0001.html>


More information about the Users mailing list