Bug 987077 - [RHEV+RHS] - Step for setting profile for tuned fails during boot-strapping, when adding RHS2.0Update5 to RHEVM 3.2 Gluster Enabled Cluster, with Compatibility version set to 3.1
Summary: [RHEV+RHS] - Step for setting profile for tuned fails during boot-strapping, ...
Keywords:
Status: CLOSED DUPLICATE of bug 987293
Alias: None
Product: ovirt-host-deploy
Classification: oVirt
Component: Plugins.tune
Version: 1.0.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Alon Bar-Lev
QA Contact: Haim
URL:
Whiteboard: gluster
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-22 16:22 UTC by Rejy M Cyriac
Modified: 2016-02-10 18:58 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
virt rhev integration
Last Closed: 2013-08-19 06:47:13 UTC
oVirt Team: Gluster
Embargoed:
pm-rhel: devel_ack?


Attachments (Terms of Use)

Description Rejy M Cyriac 2013-07-22 16:22:29 UTC
Description of problem:
On adding an RHS 2.0Update5 node to a Gluster Enabled Cluster with compatibility version set to 3.1, on RHEVM 3.2, there is a warning while installing as given below:

--------------------------------------

Host <HOSTNAME> installation in progress . Cannot set tuned profile

--------------------------------------

But the installation is completed successfully, and the node is rebooted, added to the cluster. A look at the logs show that boot-strapping is attempting to set an invalid profile of 'virtual-host' for tuned.

--------------------------------------

2013-07-22 15:35:16 DEBUG otopi.plugins.ovirt_host_deploy.tune.tuned plugin.executeRaw:347 execute: ('/usr/bin/tuned-adm', 'profile', 'virtual-host'), executable='None', cwd='None', env=None
2013-07-22 15:35:16 DEBUG otopi.plugins.ovirt_host_deploy.tune.tuned plugin.executeRaw:364 execute-result: ('/usr/bin/tuned-adm', 'profile', 'virtual-host'), rc=1
2013-07-22 15:35:16 DEBUG otopi.plugins.ovirt_host_deploy.tune.tuned plugin.execute:412 execute-output: ('/usr/bin/tuned-adm', 'profile', 'virtual-host') stdout:


2013-07-22 15:35:16 DEBUG otopi.plugins.ovirt_host_deploy.tune.tuned plugin.execute:417 execute-output: ('/usr/bin/tuned-adm', 'profile', 'virtual-host') stderr:
Invalid profile. Use 'tuned-adm list' to get all available profiles.

2013-07-22 15:35:16 WARNING otopi.plugins.ovirt_host_deploy.tune.tuned tuned._misc:81 Cannot set tuned profile

--------------------------------------

# tuned-adm active
Current active profile: default
Service tuned: enabled, running
Service ktune: disabled, stopped

--------------------------------------

The available profiles for tuned on the RHS 2.0Update5 system are given below.

--------------------------------------

# ls /etc/tune-profiles/
active-profile  desktop-powersave   functions            laptop-battery-powersave  rhs-high-throughput  server-powersave  throughput-performance
default         enterprise-storage  laptop-ac-powersave  latency-performance       rhs-virtualization   spindown-disk

--------------------------------------

If we add an RHS 2.1 node to the same cluster, we can see that the warning does not come up and below given output tells you why.

--------------------------------------

# tuned-adm active
Current active profile: virtual-host
Service tuned: enabled, running
Service ktune: enabled, running

# ls /etc/tune-profiles/
active-profile  desktop-powersave   functions            laptop-battery-powersave  rhs-high-throughput  server-powersave  throughput-performance  virtual-host
default         enterprise-storage  laptop-ac-powersave  latency-performance       rhs-virtualization   spindown-disk     virtual-guest

--------------------------------------

Version-Release number of selected component (if applicable):
RHEVM 3.2 - 3.2.1-0.39.el6ev
RHS 2.0 Update5 - glusterfs-server-3.3.0.11rhs-1.el6rhs.x86_64

How reproducible:


Steps to Reproduce:
1.On RHEVM 3.2, create POSIX compliant FS type Data Center with compatibility version 3.1
2.Create Gluster Enabled Cluster with compatibility version 3.1
3.Add RHS 2.0 Update 5 node to cluster

Actual results:

The boot-strapping of RHS 2.0Update5, even though Gluster Enabled Cluster is in compatibility version 3.1, attempts to set a profile for tuned, which is valid only for RHS 2.1 , and fails.

Expected results:

The boot-strapping of RHS 2.0Update5, for Gluster Enabled Cluster in compatibility version 3.1, should set a profile for tuned, which is valid for RHS 2.0 Update 5. And only on the boot-strapping of RHS 2.1, for Gluster Enabled Cluster in compatibility version 3.1, should the new tuned profile valid for RHS 2.1 be used.

Additional info:

Comment 1 Alon Bar-Lev 2013-07-22 19:15:53 UTC
I reduced the error to warning as older rhel do not support the virtual-host profile. So it has nothing to do with the compatibility level, but the actual distribution.

Comment 2 Rejy M Cyriac 2013-07-23 07:45:53 UTC
(In reply to Alon Bar-Lev from comment #1)
> I reduced the error to warning as older rhel do not support the virtual-host
> profile. So it has nothing to do with the compatibility level, but the
> actual distribution.

It appears that the profile being attempted to be set for tuned, on the RHS server node, is itself wrong. The profile to be set for tuned, on RHS server added to Gluster Enabled Cluster, should be 'rhs-virtualization'. This profile is available on RHS 2.0 Update 5 and RHS 2.1 . Opened BZ 987293 for that. Fix of that BZ should resolve this one.

- rejy (rmc)

Comment 3 Alon Bar-Lev 2013-08-19 06:17:01 UTC
Why don't you mark bugs as duplicate, when have the same cause?

Comment 4 Alon Bar-Lev 2013-08-19 06:18:17 UTC
More correctly why do you open new bugs?

Comment 5 Bala.FA 2013-08-19 06:40:05 UTC
I think this one is for RHS 2.0 with different compatibility version 3.1.  You could close as duplicate if this is not needed.

Comment 6 Alon Bar-Lev 2013-08-19 06:47:13 UTC
(In reply to Bala.FA from comment #5)
> I think this one is for RHS 2.0 with different compatibility version 3.1. 
> You could close as duplicate if this is not needed.

I don't know if it is needed or not as I am not familiar with your build scheme. However, usually there should be one bug to fix an issue, the cloned once to each past versions if required to fix at these as well.

So I mark it as duplicate then you can clone the other bug.

BUT: having a separate bug opened and state that this bug can be closed when the other bug is resolved, probably not good idea.

*** This bug has been marked as a duplicate of bug 987293 ***


Note You need to log in before you can comment on or make changes to this bug.