On 03/13/2014 05:33 PM, Charles Weber wrote:
On Mar 12, 2014, at 5:14 PM, Itamar Heim <ih...@redhat.com
<mailto:ih...@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
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
