Bug 1588932

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

I think instead of changing to a profile which works better we should consider changing the virtual-host config items or alias it to the profile mentioned. Else it will be a source for confusion for good. Correct me if I'm wrong here, there is no justification to maintain virtual-host profile if we are not going to use it.

(In reply to Roy Golan from comment #4)
> I think instead of changing to a profile which works better we should
> consider changing the virtual-host config items or alias it to the profile
> mentioned. Else it will be a source for confusion for good. Correct me if
> I'm wrong here, there is no justification to maintain virtual-host profile
> if we are not going to use it.

I don't agree, both latency-performance and virtual-host profiles are part of tuned package, so unless really necessary I don't wan to provide oVirt specific profile.

(In reply to Martin Perina from comment #5)
> (In reply to Roy Golan from comment #4)
> > I think instead of changing to a profile which works better we should
> > consider changing the virtual-host config items or alias it to the profile
> > mentioned. Else it will be a source for confusion for good. Correct me if
> > I'm wrong here, there is no justification to maintain virtual-host profile
> > if we are not going to use it.
> 
> I don't agree, both latency-performance and virtual-host profiles are part
> of tuned package, so unless really necessary I don't wan to provide oVirt
> specific profile.

That is my point - if virtual-host is not good for its main user, why maintain it?

(In reply to Roy Golan from comment #6)
> (In reply to Martin Perina from comment #5)
> > (In reply to Roy Golan from comment #4)
> > > I think instead of changing to a profile which works better we should
> > > consider changing the virtual-host config items or alias it to the profile
> > > mentioned. Else it will be a source for confusion for good. Correct me if
> > > I'm wrong here, there is no justification to maintain virtual-host profile
> > > if we are not going to use it.
> > 
> > I don't agree, both latency-performance and virtual-host profiles are part
> > of tuned package, so unless really necessary I don't wan to provide oVirt
> > specific profile.
> 
> That is my point - if virtual-host is not good for its main user, why
> maintain it?

AFAIK we don't maintain it, it's part of platform tuned package. In theory we could try post patches upstream to align virtual-host with latency-performance, then get this change to RHEL 8 and then try to force backport to RHEL 7, but that's too much work with unknown result (for example wouldn't be aligning virtual-host with latency-performance considered as breaking backward compatibility change?).

So I think it's more valuable to add administrators the ability to change tuned profile of the cluster ...

Of course we don't maintain it, but we are the main customer. We can modify it downstream if there is a clear benefit. 
What kind of backward compatibility breakage you see? those are kernel parameters. Unless I'm missing something.

Again if there is no parity between them, admins shouldn't be bother by the change at all, nothing. I see an advantage in keeping the profile updated, instead of changing to a different profile. Its far more intuitive, and the message you convey here is that we keep updating. With switching into a new profile we say that we don't care about it. Who will use it if its not recommended by the virtualization management itself? we will end with an outdated profile - is it worth it?

Roy's point is valid, and to elaborate on it - there's the possibility that latency-performance profile will be tweaked in the future and suddenly become unsuitable for the default profile for oVirt nodes.

A design document for changing the default value has been written, here it is even though it may become obsolete due to the above discussion:

https://docs.google.com/document/d/1MwmQKOeLo26C_SNcV4NQ7XyW_PPKSY92dTrH2iAdEA0/

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

Done. Notice, the patch is to tuned github, not ovirt

https://github.com/redhat-performance/tuned/pull/132

Moving back to MODIFIED, we need to wait until upstream changes will be included in RHEL 7 release

Still not part of current tuned in RHEL 7.

Moving to 4.3.3, but we may move even further as the fix for tuned package in RHEL should be delivered in RHEL 7.7, details in BZ1656744

Moving to 4.3.5 as it's blocked by BZ1656744 which will be part of RHEL 7.7

Moving to 4.3.6, it needs to wait for RHEL 7.7

Verified on ovirt-engine-4.3.6.3-0.1.el7.noarch with tuned-2.11.0-5.el7.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:4229