3:59 p.m.
Hi everyone,
I believe I need to change my cluster compatibility level and would like to know if I can
do this ona live cluster or if I have to change everything to maintenance mode first.
I ran engine setup and upgraded to current engine level then tried to add a new node using
the 3.3.4 el6 iso. This resulted in an error:
Host x.x.x.x is installed with VDSM version (4.14) and cannot join cluster Default which
is compatible with VDSM versions [4.13,4.9,4.11,4.12,4.10].
My current versions are:
Engine 3.3.4-1.el6 at compatibiltiy version 3.2
2 Nodes running CentOS 6.4 with VDSM 4.10.3-0.36.23.el6
Am I correct that I need to change the compatibility version to 3.3?
This has some production VMs, do I need to turn everything off first or is this a
non-interruptive change?
How will this upgrade affect my current 2 hosts at their version?
My original idea was to migrate working VMs to new ovirt ISO node and then re-install
original nodes to the same version off the 3.3.4 el6 iso.
I appreciate any advice.
Chuck
3:22 p.m.
On 03/06/2014 04:59 PM, Charles Weber wrote:
Hi everyone,
I believe I need to change my cluster compatibility level and would like to know if I can
do this ona live cluster or if I have to change everything to maintenance mode first.
I ran engine setup and upgraded to current engine level then tried to add a new node
using the 3.3.4 el6 iso. This resulted in an error:
Host x.x.x.x is installed with VDSM version (4.14) and cannot join cluster Default which
is compatible with VDSM versions [4.13,4.9,4.11,4.12,4.10].
My current versions are:
Engine 3.3.4-1.el6 at compatibiltiy version 3.2
2 Nodes running CentOS 6.4 with VDSM 4.10.3-0.36.23.el6
Am I correct that I need to change the compatibility version to 3.3?
This has some production VMs, do I need to turn everything off first or is this a
non-interruptive change?
How will this upgrade affect my current 2 hosts at their version?
My original idea was to migrate working VMs to new ovirt ISO node and then re-install
original nodes to the same version off the 3.3.4 el6 iso.
I appreciate any advice.
Chuck
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
actually no. this sounds like a bug in VDSM 4.14 not updated to report
compatibility with ovirt-engine 3.3
danken?
3:54 p.m.
This is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1067096
this was retargeted to 3.4.1
I suspect to much automation, as this should maybe block the 3.4 GA
release?
Am 11.03.2014 15:22, schrieb Itamar Heim:
On 03/06/2014 04:59 PM, Charles Weber wrote:
> Hi everyone,
> I believe I need to change my cluster compatibility level and would
> like to know if I can do this ona live cluster or if I have to change
> everything to maintenance mode first.
>
> I ran engine setup and upgraded to current engine level then tried to
> add a new node using the 3.3.4 el6 iso. This resulted in an error:
>
> Host x.x.x.x is installed with VDSM version (4.14) and cannot join
> cluster Default which is compatible with VDSM versions
> [4.13,4.9,4.11,4.12,4.10].
>
> My current versions are:
> Engine 3.3.4-1.el6 at compatibiltiy version 3.2
>
> 2 Nodes running CentOS 6.4 with VDSM 4.10.3-0.36.23.el6
>
> Am I correct that I need to change the compatibility version to 3.3?
> This has some production VMs, do I need to turn everything off first
> or is this a non-interruptive change?
> How will this upgrade affect my current 2 hosts at their version?
>
> My original idea was to migrate working VMs to new ovirt ISO node and
> then re-install original nodes to the same version off the 3.3.4 el6 iso.
>
> I appreciate any advice.
> Chuck
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
actually no. this sounds like a bug in VDSM 4.14 not updated to report
compatibility with ovirt-engine 3.3
danken?
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
3:58 p.m.
On 03/11/2014 04:54 PM, Sven Kieske wrote:
This is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1067096
this was retargeted to 3.4.1
seems 3.4.0 to me
I suspect to much automation, as this should maybe block the 3.4 GA
release?
Am 11.03.2014 15:22, schrieb Itamar Heim:
> On 03/06/2014 04:59 PM, Charles Weber wrote:
>> Hi everyone,
>> I believe I need to change my cluster compatibility level and would
>> like to know if I can do this ona live cluster or if I have to change
>> everything to maintenance mode first.
>>
>> I ran engine setup and upgraded to current engine level then tried to
>> add a new node using the 3.3.4 el6 iso. This resulted in an error:
>>
>> Host x.x.x.x is installed with VDSM version (4.14) and cannot join
>> cluster Default which is compatible with VDSM versions
>> [4.13,4.9,4.11,4.12,4.10].
>>
>> My current versions are:
>> Engine 3.3.4-1.el6 at compatibiltiy version 3.2
>>
>> 2 Nodes running CentOS 6.4 with VDSM 4.10.3-0.36.23.el6
>>
>> Am I correct that I need to change the compatibility version to 3.3?
>> This has some production VMs, do I need to turn everything off first
>> or is this a non-interruptive change?
>> How will this upgrade affect my current 2 hosts at their version?
>>
>> My original idea was to migrate working VMs to new ovirt ISO node and
>> then re-install original nodes to the same version off the 3.3.4 el6 iso.
>>
>> I appreciate any advice.
>> Chuck
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
> actually no. this sounds like a bug in VDSM 4.14 not updated to report
> compatibility with ovirt-engine 3.3
> danken?
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
4:35 p.m.
Sorry, I just read to quick over the BZ, you're right :)
Would it be worth backporting this to 3.3.5 ?
If I understand this correctly you are not able to
use vdsm 4.14 with any ovirt-engine version < 3.4.0 ?
at least then ovirt-engine 3.3.x shouldn't try to
deploy vdsm 4.14 on hosts.
Am 11.03.2014 15:58, schrieb Itamar Heim:
seems 3.4.0 to me
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
5:38 p.m.
On 03/11/2014 05:35 PM, Sven Kieske wrote:
Sorry, I just read to quick over the BZ, you're right :)
Would it be worth backporting this to 3.3.5 ?
If I understand this correctly you are not able to
use vdsm 4.14 with any ovirt-engine version < 3.4.0 ?
i understood this to "you can't use 4.14 with 3.4.0".
at least then ovirt-engine 3.3.x shouldn't try to
deploy vdsm 4.14 on hosts.
it should.
Am 11.03.2014 15:58, schrieb Itamar Heim:
> seems 3.4.0 to me
9:11 a.m.
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
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
9:15 a.m.
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?
3:25 p.m.
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.
3:32 p.m.
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?
the issue was verified in
https://bugzilla.redhat.com/show_bug.cgi?id=1016461 , please reopen if
it still appears
--
Yaniv Bronhaim.
3:33 p.m.
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.
the issue was verified in
https://bugzilla.redhat.com/show_bug.cgi?id=1016461 , please reopen if
it still appears
9:45 p.m.
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
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
>
>
>
--
Yaniv Bronhaim.
10:14 p.m.
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
>>
>>
>>
>
4:33 p.m.
--Apple-Mail=_DBDEE8BE-C036-4EB7-8792-8529E5E0E9DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Mar 12, 2014, at 5:14 PM, Itamar Heim <iheim(a)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:
>>>>>>=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
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.=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.
Engine 3.3.4-1.el6
CO6.5
Nodes are 3.0.4-1.0.201401291204.el6
Storage is SAN
--Apple-Mail=_DBDEE8BE-C036-4EB7-8792-8529E5E0E9DD
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><div>On Mar 12, 2014, at
5:14 PM, =
Itamar Heim <<a =
href=3D"mailto:iheim@redhat.com">iheim@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;">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&quo...
bugzilla.redhat.com/show_bug.cgi?id=3D1067096#c0</a><br><b...
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 =
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 =
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 engine. but that's not supposed to be an =
issue, since its supposed to 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"&...
zilla.redhat.com/show_bug.cgi?id=3D1016461</a><span =
class=3D"Apple-converted-space"> </span>, please reopen
if<br>it =
still =
appears<br><br><br><br></blockquote><br></blockquote><br><br></blockquote>=
<br></div></blockquote></div><div><br></div>I do
have an issue still =
with this.</div><div>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.</div><div><br></div><div>I would like to change to
3.3. Can you =
direct me to the sql table or cmd line by any =
chance. </div><div><br></div><div>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.</div><div><br></div><div>Engine =
3.3.4-1.el6</div><div>CO6.5</div><div>Nodes are =
3.0.4-1.0.201401291204.el6</div><div>Storage is =
SAN</div><div><br></div><div><br></div></body></html>=
--Apple-Mail=_DBDEE8BE-C036-4EB7-8792-8529E5E0E9DD--
11:58 p.m.
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?
Engine 3.3.4-1.el6
CO6.5
Nodes are 3.0.4-1.0.201401291204.el6
Storage is SAN
10:04 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Charles Weber" <chaweber(a)gmail.com>
Cc: "ybronhei" <ybronhei(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>, users(a)ovirt.org, "Eli Mesika"
<emesika(a)redhat.com>, "Sven Kieske" <S.Kieske(a)mittwald.de>,
"Omer Frenkel" <ofrenkel(a)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(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)?
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
>
>
9:41 a.m.
----- Original Message -----
From: "Omer Frenkel" <ofrenkel(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>, "Tomas Jelinek"
<tjelinek(a)redhat.com>
Cc: "Charles Weber" <chaweber(a)gmail.com>, "ybronhei"
<ybronhei(a)redhat.com>, "Dan Kenigsberg" <danken(a)redhat.com>,
users(a)ovirt.org, "Eli Mesika" <emesika(a)redhat.com>, "Sven
Kieske" <S.Kieske(a)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(a)redhat.com>
> To: "Charles Weber" <chaweber(a)gmail.com>
> Cc: "ybronhei" <ybronhei(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>,
> users(a)ovirt.org, "Eli Mesika"
> <emesika(a)redhat.com>, "Sven Kieske" <S.Kieske(a)mittwald.de>,
"Omer Frenkel"
> <ofrenkel(a)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(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
> >
> >
>
>
8: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(a)redhat.com> wrote:
=20
=20
----- Original Message -----
> From: "Omer Frenkel" <ofrenkel(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>, "Tomas Jelinek" =
<tjelinek(a)redhat.com>
> Cc: "Charles Weber" <chaweber(a)gmail.com>,
"ybronhei" =
<ybronhei(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>,
> users(a)ovirt.org, "Eli Mesika"
<emesika(a)redhat.com>, "Sven Kieske" =
<S.Kieske(a)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(a)redhat.com>
>> To: "Charles Weber" <chaweber(a)gmail.com>
>> Cc: "ybronhei" <ybronhei(a)redhat.com>, "Dan Kenigsberg"
=
<danken(a)redhat.com>,
>> users(a)ovirt.org, "Eli Mesika"
>> <emesika(a)redhat.com>, "Sven Kieske" <S.Kieske(a)mittwald.de>,
"Omer =
Frenkel"
>> <ofrenkel(a)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(a)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&quo...
bugzilla.redhat.com/show_bug.cgi?id=3D1067096#c0</a><br><b...
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"&...
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--
8:23 a.m.
----- Original Message -----
From: "Charles Weber" <chaweber(a)gmail.com>
To: "Tomas Jelinek" <tjelinek(a)redhat.com>
Cc: "Omer Frenkel" <ofrenkel(a)redhat.com>, users(a)ovirt.org, "Sven
Kieske" <S.Kieske(a)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(a)redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Omer Frenkel" <ofrenkel(a)redhat.com>
>> To: "Itamar Heim" <iheim(a)redhat.com>, "Tomas Jelinek"
>> <tjelinek(a)redhat.com>
>> Cc: "Charles Weber" <chaweber(a)gmail.com>, "ybronhei"
>> <ybronhei(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>,
>> users(a)ovirt.org, "Eli Mesika" <emesika(a)redhat.com>, "Sven
Kieske"
>> <S.Kieske(a)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(a)redhat.com>
>>> To: "Charles Weber" <chaweber(a)gmail.com>
>>> Cc: "ybronhei" <ybronhei(a)redhat.com>, "Dan
Kenigsberg"
>>> <danken(a)redhat.com>,
>>> users(a)ovirt.org, "Eli Mesika"
>>> <emesika(a)redhat.com>, "Sven Kieske"
<S.Kieske(a)mittwald.de>, "Omer
>>> Frenkel"
>>> <ofrenkel(a)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(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
- 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.
4095
days inactive
4107
days old
18 comments
7 participants
participants (7)
-
Charles Weber -
Dan Kenigsberg -
Itamar Heim -
Omer Frenkel -
Sven Kieske -
Tomas Jelinek -
ybronhei