17 Mar
2014
17 Mar
'14
6:44 p.m.
--Apple-Mail=_5D5BB5F6-7307-4BC7-A153-7C93F9E36ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 17, 2014, at 4:41 AM, Tomas Jelinek <tjelinek@redhat.com> wrote: >=20 >=20 > ----- Original Message ----- >> From: "Omer Frenkel" <ofrenkel@redhat.com> >> To: "Itamar Heim" <iheim@redhat.com>, "Tomas Jelinek" = <tjelinek@redhat.com> >> Cc: "Charles Weber" <chaweber@gmail.com>, "ybronhei" = <ybronhei@redhat.com>, "Dan Kenigsberg" <danken@redhat.com>, >> users@ovirt.org, "Eli Mesika" <emesika@redhat.com>, "Sven Kieske" = <S.Kieske@mittwald.de> >> Sent: Sunday, March 16, 2014 10:04:12 AM >> Subject: Re: [Users] affects of changing compatibility setting on = running cluster >>=20 >>=20 >>=20 >> ----- Original Message ----- >>> From: "Itamar Heim" <iheim@redhat.com> >>> To: "Charles Weber" <chaweber@gmail.com> >>> Cc: "ybronhei" <ybronhei@redhat.com>, "Dan Kenigsberg" = <danken@redhat.com>, >>> users@ovirt.org, "Eli Mesika" >>> <emesika@redhat.com>, "Sven Kieske" <S.Kieske@mittwald.de>, "Omer = Frenkel" >>> <ofrenkel@redhat.com> >>> Sent: Friday, March 14, 2014 12:58:57 AM >>> Subject: Re: [Users] affects of changing compatibility setting on = running >>> cluster >>>=20 >>> On 03/13/2014 05:33 PM, Charles Weber wrote: >>>>=20 >>>> On Mar 12, 2014, at 5:14 PM, Itamar Heim <iheim@redhat.com >>>> <mailto:iheim@redhat.com>> wrote: >>>>=20 >>>>> 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: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Am 11.03.2014 17:38, schrieb Itamar Heim: >>>>>>>>>>>>=20 >>>>>>>>>>>> i understood this to "you can't use 4.14 with 3.4.0". >>>>>>>>>>>=20 >>>>>>>>>>> Well I examined BZ 1067096 again, this is what did not work: >>>>>>>>>>>=20 >>>>>>>>>>> Steps to Reproduce: >>>>>>>>>>> 1. Run Engine 3.3 Compatibility level 3.2 or 3.3 >>>>>>>>>>> 2. Add node (vdsm 4.14) >>>>>>>>>>>=20 >>>>>>>>>>> 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]. >>>>>>>>>>>=20 >>>>>>>>>>> Pay attention to the engine version, it states 3.3. not = 3.4.0 >>>>>>>>>>>=20 >>>>>>>>>>> So my conclusion is, you can't install vdsm 4.14. when you = want >>>>>>>>>>> to use engine 3.3. >>>>>>>>>>>=20 >>>>>>>>>>> Am I reading something wrong? >>>>>>>>>>>=20 >>>>>>>>>>> Here's the link again: >>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1067096#c0 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 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'], >>>>>>>>>>=20 >>>>>>>>>> danken/eli - thoughts? >>>>>>>>>=20 >>>>>>>>> I do not really understand why we have this recurrent Engine = bug, of >>>>>>>>> ignoring supportedENGINEs; I think Yaniv does. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>> if vdsm version is supported why isn't it in engine's = capabilities >>>>>>>> yet? >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>=20 >>>>>> so its an hack to allow users to add beta vdsm version to new = engine >>>>>> release?.. sounds like that >>>>>=20 >>>>> 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) >>>>>=20 >>>>>>=20 >>>>>> please reopen if it reproduced >>>>>>=20 >>>>>>>>=20 >>>>>>>> the issue was verified in >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1016461, please = reopen if >>>>>>>> it still appears >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> I would like to change to 3.3. Can you direct me to the sql table = or cmd >>>> line by any chance. >>>=20 >>> do not hack the db for such a change, you may skip important upgrade >>> logic/validation. >>>=20 >>>>=20 >>>> 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. >>>=20 >>> sounds like a bug, at least for not telling you what is the error. >>> omer - thoughts? >>>=20 >>=20 >> 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)? >=20 > 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). >=20 >=20 >>=20 >> adding Tomas, might have a better idea. >>=20 >> you can try updating using rest api (change user/pass and cluster = uuid): >>=20 >> 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=3D\"3\" minor=3D\"3\"/></cluster>" >>=20 >>=20 >>>>=20 >>>> 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. --Apple-Mail=_5D5BB5F6-7307-4BC7-A153-7C93F9E36ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><br><div><div>On Mar 17, 2014, at 4:41 AM, Tomas = Jelinek <<a = href=3D"mailto:tjelinek@redhat.com">tjelinek@redhat.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: auto; word-spacing: = 0px; -webkit-text-stroke-width: 0px;"><br><br>----- Original Message = -----<br><blockquote type=3D"cite">From: "Omer Frenkel" <<a = href=3D"mailto:ofrenkel@redhat.com">ofrenkel@redhat.com</a>><br>To: = "Itamar Heim" <<a = href=3D"mailto:iheim@redhat.com">iheim@redhat.com</a>>, "Tomas = Jelinek" <<a = href=3D"mailto:tjelinek@redhat.com">tjelinek@redhat.com</a>><br>Cc: = "Charles Weber" <<a = href=3D"mailto:chaweber@gmail.com">chaweber@gmail.com</a>>, = "ybronhei" <<a = href=3D"mailto:ybronhei@redhat.com">ybronhei@redhat.com</a>>, "Dan = Kenigsberg" <<a = href=3D"mailto:danken@redhat.com">danken@redhat.com</a>>,<br><a = href=3D"mailto:users@ovirt.org">users@ovirt.org</a>, "Eli Mesika" <<a = href=3D"mailto:emesika@redhat.com">emesika@redhat.com</a>>, "Sven = Kieske" <<a = href=3D"mailto:S.Kieske@mittwald.de">S.Kieske@mittwald.de</a>><br>Sent:= Sunday, March 16, 2014 10:04:12 AM<br>Subject: Re: [Users] affects of = changing compatibility setting on running cluster<br><br><br><br>----- = Original Message -----<br><blockquote type=3D"cite">From: "Itamar Heim" = <<a href=3D"mailto:iheim@redhat.com">iheim@redhat.com</a>><br>To: = "Charles Weber" <<a = href=3D"mailto:chaweber@gmail.com">chaweber@gmail.com</a>><br>Cc: = "ybronhei" <<a = href=3D"mailto:ybronhei@redhat.com">ybronhei@redhat.com</a>>, "Dan = Kenigsberg" <<a = href=3D"mailto:danken@redhat.com">danken@redhat.com</a>>,<br><a = href=3D"mailto:users@ovirt.org">users@ovirt.org</a>, "Eli = Mesika"<br><<a = href=3D"mailto:emesika@redhat.com">emesika@redhat.com</a>>, "Sven = Kieske" <<a = href=3D"mailto:S.Kieske@mittwald.de">S.Kieske@mittwald.de</a>>, "Omer = Frenkel"<br><<a = href=3D"mailto:ofrenkel@redhat.com">ofrenkel@redhat.com</a>><br>Sent: = Friday, March 14, 2014 12:58:57 AM<br>Subject: Re: [Users] affects of = changing compatibility setting on running<br>cluster<br><br>On = 03/13/2014 05:33 PM, Charles Weber wrote:<br><blockquote = type=3D"cite"><br>On Mar 12, 2014, at 5:14 PM, Itamar Heim <<a = href=3D"mailto:iheim@redhat.com">iheim@redhat.com</a><br><<a = href=3D"mailto:iheim@redhat.com">mailto:iheim@redhat.com</a>>> = wrote:<br><br><blockquote type=3D"cite">On 03/12/2014 10:45 PM, ybronhei = wrote:<br><blockquote type=3D"cite">On 03/12/2014 04:33 PM, Itamar Heim = wrote:<br><blockquote type=3D"cite">On 03/12/2014 04:32 PM, ybronhei = wrote:<br><blockquote type=3D"cite">On 03/12/2014 04:25 PM, Dan = Kenigsberg wrote:<br><blockquote type=3D"cite">On Wed, Mar 12, 2014 at = 10:15:21AM +0200, Itamar Heim wrote:<br><blockquote type=3D"cite">On = 03/12/2014 10:11 AM, Sven Kieske wrote:<br><blockquote = type=3D"cite"><br><br>Am 11.03.2014 17:38, schrieb Itamar = Heim:<br><blockquote type=3D"cite"><br>i understood this to "you can't = use 4.14 with 3.4.0".<br></blockquote><br>Well I examined BZ 1067096 = again, this is what did not work:<br><br>Steps to Reproduce:<br>1. = Run Engine 3.3 Compatibility level 3.2 or 3.3<br>2. Add node = (vdsm 4.14)<br><br>Actual results:<br>Host is installed with VDSM = version (4.14) and cannot join cluster<br>which<br>is compatible with = VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10].<br><br>Pay attention to the = engine version, it states 3.3. not 3.4.0<br><br>So my conclusion is, you = can't install vdsm 4.14. when you want<br>to use engine 3.3.<br><br>Am I = reading something wrong?<br><br>Here's the link again:<br><a = href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1067096#c0">https://= bugzilla.redhat.com/show_bug.cgi?id=3D1067096#c0</a><br><br></blockquote><= br>this can be fixed via engine config, but is not supposed to = be<br>needed, as vdsm is supposed to have<br>vdsm/dsaversion.py.in: = 'supportedENGINEs': ['3.0', '3.1', '3.2',<br>'3.3', = '3.4'],<br><br>danken/eli - thoughts?<br></blockquote><br>I do not = really understand why we have this recurrent Engine bug, of<br>ignoring = supportedENGINEs; I think Yaniv does.<br><br></blockquote><br>i recall = asking for detailed explanation for why do we have = 3<br>different<br>restrictions , one for supportedEngines, one for the = allowed vdsm<br>versions, and one for the cluster level?<br><br>if vdsm = version is supported why isn't it in engine's = capabilities<br>yet?<br></blockquote><br>because its a vdsm version = which was released after that engine was<br>released, hence the vdsm = package has to declare its supporting the = old<br>engine.<br><br></blockquote><br>so its an hack to allow users to = add beta vdsm version to new engine<br>release?.. sounds like = that<br></blockquote><br>no. its to add the next release of vdsm to a = previously released<br>engine. but that's not supposed to be an issue, = since its supposed to<br>already report the previous version of engine = (which it does)<br><br><blockquote type=3D"cite"><br>please reopen if it = reproduced<br><br><blockquote type=3D"cite"><blockquote = type=3D"cite"><br>the issue was verified in<br><a = href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1016461">https://bug= zilla.redhat.com/show_bug.cgi?id=3D1016461</a>, please reopen if<br>it = still = appears<br><br><br><br></blockquote><br></blockquote><br><br></blockquote>= <br></blockquote><br>I do have an issue still with this.<br>When I try = to change compatibility version at the datacenter level it<br>behaves as = expected, i.e. warns me to change the cluster level first. I<br>see a = matching log entry in the engine log. However when I try to = change<br>the compatibility version at the cluster level the edit = cluster dialog<br>box just hangs there. There are no log entries in the = engine log. The<br>dialog box goes away when I click cancel. If I select = 3.2 or 3.3 and<br>click OK nothing happens. This occurs either during = normal running or<br>with hosts in maintenance mode.<br><br>I would like = to change to 3.3. Can you direct me to the sql table or cmd<br>line by = any chance.<br></blockquote><br>do not hack the db for such a change, = you may skip important upgrade<br>logic/validation.<br><br><blockquote = type=3D"cite"><br>Is this a known problem or something specific to my = special setup.<br> Actually my setup is pretty plain, see below or = original post in this<br>thread.<br></blockquote><br>sounds like a bug, = at least for not telling you what is the error.<br>omer - = thoughts?<br><br></blockquote><br>if nothing happens when clicking ok = it's usually some validation in the<br>dialog,<br>can you check there is = nothing highlighted in red (check also other tabs in<br>the = dialog)?<br></blockquote><br>Indeed, can be a validation problem (the = better case) or can be an exception on FE (worse case).<br>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?<br>(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<br>send it and tell me also = on what browser have you simulated it in).<br><br><br><blockquote = type=3D"cite"><br>adding Tomas, might have a better idea.<br><br>you can = try updating using rest api (change user/pass and cluster = uuid):<br><br>curl -X PUT -H "Accept: application/xml" -H "Content-Type: = application/xml"<br>-u "admin@internal:password"<br>"<a = href=3D"http://localhost:8080/api/clusters/dd746d43-4bd1-46aa-b97b-b7bad3f= 2e498">http://localhost:8080/api/clusters/dd746d43-4bd1-46aa-b97b-b7bad3f2= e498</a>" -d<br>"<cluster><version major=3D\"3\" = minor=3D\"3\"/></cluster>"<br><br><br><blockquote = type=3D"cite"><blockquote type=3D"cite"><br>Engine = 3.3.4-1.el6<br>CO6.5<br>Nodes are 3.0.4-1.0.201401291204.el6<br>Storage = is SAN</blockquote></blockquote></blockquote></div></blockquote></div>1. = No red on of the browser window forms when I try to change from = 3.2 to 3.3<div>2. Used firefox 27.0.1 on Mac to test this = now.</div><div>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.</div><div>4. I will look at the rest = statement.</div><br></body></html>= --Apple-Mail=_5D5BB5F6-7307-4BC7-A153-7C93F9E36ED3--