Re: [Users] affects of changing compatibility setting on running cluster

From: "Charles Weber" <chaweber(a)gmail.com&gt; To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; Cc: "Omer Frenkel" <ofrenkel(a)redhat.com&gt;, users(a)ovirt.org, "Sven Kieske" <S.Kieske(a)mittwald.de&gt; Sent: Monday, March 17, 2014 8:44:09 PM Subject: Re: [Users] affects of changing compatibility setting on running cluster On Mar 17, 2014, at 4:41 AM, Tomas Jelinek <tjelinek(a)redhat.com&gt; wrote: > > > ----- Original Message ----- >> From: "Omer Frenkel" <ofrenkel(a)redhat.com&gt; >> To: "Itamar Heim" <iheim(a)redhat.com&gt;, "Tomas Jelinek" >> <tjelinek(a)redhat.com&gt; >> Cc: "Charles Weber" <chaweber(a)gmail.com&gt;, "ybronhei" >> <ybronhei(a)redhat.com&gt;, "Dan Kenigsberg" <danken(a)redhat.com&gt;, >> users(a)ovirt.org, "Eli Mesika" <emesika(a)redhat.com&gt;, "Sven Kieske" >> <S.Kieske(a)mittwald.de&gt; >> 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(a)redhat.com&gt; >>> To: "Charles Weber" <chaweber(a)gmail.com&gt; >>> Cc: "ybronhei" <ybronhei(a)redhat.com&gt;, "Dan Kenigsberg" >>> <danken(a)redhat.com&gt;, >>> users(a)ovirt.org, "Eli Mesika" >>> <emesika(a)redhat.com&gt;, "Sven Kieske" <S.Kieske(a)mittwald.de&gt;, "Omer >>> Frenkel" >>> <ofrenkel(a)redhat.com&gt; >>> 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(a)redhat.com >>>> <mailto:iheim@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@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.