[Users] affects of changing compatibility setting on running cluster

Tue Mar 18 07:23:15 UTC 2014


----- Original Message -----
> From: "Charles Weber" <chaweber at gmail.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "Omer Frenkel" <ofrenkel at redhat.com>, users at ovirt.org, "Sven Kieske" <S.Kieske at mittwald.de>
> 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 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

- Please make sure that there is no red border around any field on any of the side tabs (not only general)
- Please try only open the edit dialog, change nothing and press OK again if that works.

> 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.

- if no exception, on the frontend and no log statement on the server after pressing ok and also nothing marked as red, 
  it can be a validation mistake on a field which is not visible (e.g. a bug). You could verify this by 
  some tool like firebug (for firefox) and trying to make all the fields on that dialog visible (in all the tabs) and try to
  find the one which is suspiciously empty or just marked with a red border. If you find it than fill it properly and try to press ok again.

> 4. I will look at the rest statement.
> 
>