Bug 1151488

Yaniv/Oved, there needs to be a proper engine side fix as well. In 3.5 (in contrast to 3.4.z) the engine requires the packages to be reported for some reason. This is probably a regression in engine
We want the vdsm fix for sure, but the engine side needs to be addressed too

(In reply to Michal Skrivanek from comment #3)
> Yaniv/Oved, there needs to be a proper engine side fix as well. In 3.5 (in
> contrast to 3.4.z) the engine requires the packages to be reported for some
> reason. This is probably a regression in engine
> We want the vdsm fix for sure, but the engine side needs to be addressed too

As long as there are package version the engine should know to cope with that.
What additional fix you had in mind?

3.4 engine works even when the pkgs are not reported. "packages2" should not be needed for joining the cluster. The vdsm version is reported in other field which should be used.
So it is a 3.5 regression in engine I guess; or at least a 3.5-only problem in engine.

 please verify that with the attached patch and see that engine adds the host properly. afaiu if engine didn't fail the addHost to cluster in 3.4 before, its due to a bug that was fixed regarding the version validation between 3.4 to 3.5. with unknown version engine should fail it

Yes it works with 3.4.3 without problem (vdsm-4.14.17-1.pkvm2_1.ppc64).

The vdsm-side patch would get to 3.4.4. But it seems that there has been an unintentional behavioral change in Engine. Please consider fixing it in 3.5.1.

*** Bug 1151489 has been marked as a duplicate of this bug. ***

please also read bug 1151489 for more details
we need to fix engine behavior in 3.5 to look at proper variables. 
Oved, can you please prioritize?

We need to work with ppc host for that, and sometimes it delays the work a bit. I move that to 3.5.1 as it requires verification and debugging to understand the change in HandleVdsVersionCommand or the version parsing

Starting to verify this issue and I need to clarify the answer:

Revisiting this area again (HandleVdsVersionCommand) I see again that firstly engine checks isEngineSupportedByVdsm by checking the supported engine value from getCaps (example from vdsm 3.5: supportedENGINEs = ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5']). this returned normally regarding the ppc bug which lead to unreported rpm versions. 

In the case where engine supported by vdsm - like vdsm and engine 3.5, all works and you won't see the UNKNOWN eventhough vdsm version is not reported properly (you see it in the UI - VDSM Version: [N/A] in host's tab).

But if the supportedByVdsm is false, and vdsm version is not reported, such as this case, you will see the report:
Host a1a1 is installed with VDSM version (<UNKNOWN>) and cannot join cluster Default which is compatible with VDSM versions [4.13, 4.14, 4.9, 4.11, 4.15, 4.12, 4.10].

saying that, not sure what is your case. but the code is similar both in 3.5 and 3.4, it just depends on the versions you run

I intend to close it as NOTABUG.

(In reply to Yaniv Bronhaim from comment #13)
> Starting to verify this issue and I need to clarify the answer:
> 
> Revisiting this area again (HandleVdsVersionCommand) I see again that
> firstly engine checks isEngineSupportedByVdsm by checking the supported
> engine value from getCaps (example from vdsm 3.5: supportedENGINEs = ['3.0',
> '3.1', '3.2', '3.3', '3.4', '3.5']). this returned normally regarding the
> ppc bug which lead to unreported rpm versions. 
> 
> In the case where engine supported by vdsm - like vdsm and engine 3.5, all
> works and you won't see the UNKNOWN eventhough vdsm version is not reported
> properly (you see it in the UI - VDSM Version: [N/A] in host's tab).
> 
> But if the supportedByVdsm is false, and vdsm version is not reported, such
> as this case, you will see the report:
> Host a1a1 is installed with VDSM version (<UNKNOWN>) and cannot join cluster
> Default which is compatible with VDSM versions [4.13, 4.14, 4.9, 4.11, 4.15,
> 4.12, 4.10].
> 
> saying that, not sure what is your case. but the code is similar both in 3.5
> and 3.4, it just depends on the versions you run
> 
> I intend to close it as NOTABUG.

The only claim by Michal was that without applying your fix it worked well in 3.4, but not in 3.5.
I also remember that the code is the same, and I think it probably worked well in a bit different use-case. We've been doing this validation a long time now, and that's the correct one.

Closing this one. Michal - if you notice anything wrong with the logic/behavior, please reopen.

I suppose the statement in #13 was never tested.

Reproduces with vt7 (3.5.0-0.17.beta.el6e) and vdsm-4.14.17-10.gitbb25d3b.el7.ppc64

2014-Oct-27, 09:49
Host ibm-p8-rhevm-03.rhts.eng.bos.redhat.com is installed with VDSM version (<UNKNOWN>) and cannot join cluster ppc64 which is compatible with VDSM versions [4.13, 4.14, 4.9, 4.11, 4.15, 4.12, 4.10].

Yes, it is _3.5_ !

According to some discussion it's strange a BZ can be switched from ASSIGNED to CLOSED/WORKSFORME.

We need to verify that the following works:
1. Work with engine 3.5
2. Work with the most updated PPC VDSM version
3. Try to add the host to the engine
4. Make sure it works

If it works well, we can close this one.
If not, we need to apply the fix to make it work.

Jiri - Yaniv can verify that if he gets access to the host.
Or you help us verify that.

The bug was closed due to understanding it works with latest 3.5 release + latest 3.4 PPC vdsm release. If it doesn't, then we have an issue. If it does, it can be either moved to MODIFIED for proper verification, or closed.

(In reply to Oved Ourfali from comment #16)
> We need to verify that the following works:
> 1. Work with engine 3.5

see above

> 2. Work with the most updated PPC VDSM version

NAME="RHEV for IBM POWER"
VERSION="3.4"
ID="rhev for ibm power"
VERSION_ID="3.4"
BUILD_ID="36.0-service"
PRETTY_NAME="RHEV for IBM POWER 3.4"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:ibm:service:pkvm2_1"

> 3. Try to add the host to the engine
> 4. Make sure it works

no it does not

> If it works well, we can close this one.
> If not, we need to apply the fix to make it work.
> 
> Jiri - Yaniv can verify that if he gets access to the host.
> Or you help us verify that.
> 
> The bug was closed due to understanding it works with latest 3.5 release +
> latest 3.4 PPC vdsm release. If it doesn't, then we have an issue. If it
> does, it can be either moved to MODIFIED for proper verification, or closed.

"understanding it works" - then it should be CLOSEDCURRENTRELEASE, no?

just to clarify (again):

- vdsm is rhev for power (3.4)
- engine is d/s 3.5 (it is *obvious* the cluster level is 3.4)

The reason it works on 3.4 and not 3.5, is because the engine is 3.5, and vdsm is 3.4, so the supportedEngines entry in VDSM doesn't contain 3.5, thus we check for the package version. In 3.4 it isn't checked because 3.4 is a supported engine by VDSM.

For verification reasons, I'm moving this one to MODIFIED, to be verified once 3.4.4 is released.

Note that it can be verified only once 3.4.4 is out.

(In reply to Oved Ourfali from comment #18)
> The reason it works on 3.4 and not 3.5, is because the engine is 3.5, and
> vdsm is 3.4, so the supportedEngines entry in VDSM doesn't contain 3.5, thus
> we check for the package version. In 3.4 it isn't checked because 3.4 is a
> supported engine by VDSM.

aah, now it makes sense. Thanks for clarification!

> For verification reasons, I'm moving this one to MODIFIED, to be verified
> once 3.4.4 is released.

yes. it's *not* in RHEV for Power build 36, that is based on 3.4.3

> yes. it's *not* in RHEV for Power build 36, that is based on 3.4.3

how can we understand the relation between RHEV for Power builds and vdsm version (without comparing rpm packages inside power build)?

the rpm versions are the same

ok, vt9 with vdsm 4.14.18-1 (https://bugzilla.redhat.com/show_bug.cgi?id=1152448#c4)

rhev 3.5.0 was released. closing.