Hardcoded active profile
jhg03a opened this issue · comments
In your ERB template to create the custom tuned conf, you hardcoded that it was a virtual-guest instead of detecting the active profile and basing it off that.
Hi there, I just followed the MongoDB instructions I think. Do you have a link documenting what you think I should do instead?
Hi @jhg03a I'm trying to fix up the PR you sent in. Now I'm confused about something. How does your /etc/tuned/custom/tuned.conf file get created in the first place - shouldn't Puppet be managing this file too?
I'm a bit confused by your question. It's created the same way your original work did, by rendering the erb template. All I did was to create the pair of custom facts needed to model the setting prior to creating a new custom profile. As a side-effect, it also will update if you change the tuned profile after the custom one is in place correctly.
Hi @jhg03a I'm going to look into this more deeply when I have a chance, but it'd be really helpful if you could give me more info about your platform, how it was built, so I could reproduce the issue you had?
RHEL7x64 Minimum install. I have installs on both physical and virtual systems.
The ERB template you used to create your tuned.conf had the profile "virtual-guest" hardcoded in it, which is incorrect in a physical server. So before your module overwrote the profile that was in place beforehand, I capture the information in a puppet custom fact. That way the ERB template can keep what you had beforehand as the base, such as "throughput-performance".
Ah thanks. That's the bit I'm missing. No, I haven't tested this on physical hardware. I'll see if I can get access to something to test on. Thanks very much for all your input.
@jhg03a I don't suppose you have access to a clean physical server with examples of the relevant files in their state prior to puppet's changes? I could use those files to set up Rspec tests, since I don't have access to actual physical hardware. If not, no worries.
Unfortunately not, I kickstart directly into a puppet setup.
Well, Puppet saves copies of all the files it changes in the Filebucket and here's how you can find the original content (in case you don't already know):
make Puppet change some file:
[root@localhost ~]# puppet resource file /etc/centos-release content='alex was here'
Notice: /File[/etc/centos-release]/content: content changed '{md5}54c7625ec4cc8e9dc7d9a1ed0fe85d41' to '{md5}520c9bab8b3c5584aca2d4e4ee472952'
file { '/etc/centos-release':
ensure => 'file',
content => '{md5}520c9bab8b3c5584aca2d4e4ee472952',
}
Find Puppet's file bucket:
[root@localhost ~]# puppet config print clientbucketdir
/opt/puppetlabs/puppet/cache/clientbucket
Grep that dir for the file path you're trying to view or restore:
[root@localhost ~]# grep -r /etc/centos-release /opt/puppetlabs/puppet/cache/clientbucket
/opt/puppetlabs/puppet/cache/clientbucket/5/4/c/7/6/2/5/e/54c7625ec4cc8e9dc7d9a1ed0fe85d41/paths:/etc/centos-release
View its contents:
[root@localhost ~]# cat /opt/puppetlabs/puppet/cache/clientbucket/5/4/c/7/6/2/5/e/54c7625ec4cc8e9dc7d9a1ed0fe85d41/contents
CentOS Linux release 7.2.1511 (Core)
Cool. I went pack in puppetdb to find the hash, but it would appear custom/tuned.conf was created by the module to begin with. The physical system had a default profile of throughput-performance.
Yeah that was my understanding, that my module would create this file, so I was confused about the logic of expecting it to already exist. When you say it had a default profile of throughput-performance, you mean /etc/tuned/active_profile began with throughput-performance, and you think the ISO put it there?
Yes. When Tuned is installed with the OS, it picks a default based on different criteria. I looked to active_profile first, then fallback to using the actual tuned command if for any reason it doesn't exist to know how things started. It also means that tomorrow if I do a manual change of profile from custom to power-saver, it will update custom's base and reapply custom.
Ah ok, I understand your thinking better now. Best practice though is to assume that no manual changes will ever occur. Have you considered using a module for tuned, e.g. here? Of course, that raises the question, how would my module play with another module that manages tuned. Hm, this is more complicated than I realised. :)
@jhg03a I've been looking at this today and trying to figure out how to fix this up properly, and I've decided that, I'm sorry, but I'm going to have to revert these changes. I can see why you might want the freedom to make manual changes on physical hardware, although if that was my situation and my choice, I would also choose to disable huge pages manually too. If you believe I should be supporting this configuration, I'm more than happy to discuss it some more, and I'll leave this open till I hear back from you.
Have you considered a Kickstart Post Install script to disable THP? Having thought about it some more, I think that's what I'd do if I wanted to manage tuned manually, but let Puppet configure everything else.
Yes, but I didn't want to go down that route because I didn't want to specialize my kickstart scripts for specific use cases.
I could perhaps add a feature to optionally not touch tuned in the case where people manage tuned using a tuned module. You could then have the tuned module take care of the tuned part and have this module do the rest. Would that work ?
Or you can just fork or point back to an earlier commit of course. :)
I think your original scope was fine. It solves the problem for me once I have that PR I wrote pulled in. I don't have a strong reason to micromanage the tuned settings outside this exception. Therefore it solves the problem for me just fine.
I'm sorry but I can't support a use-case of interactions with manual processes or other tools. I think a better solution is for me to add a feature that turns off this module's tuned interactions so that another tool can handle that part. You can then copy the code from this module into your roles & profiles code, along with the feature that you PR'ed. Unless I've misunderstood something, I don't think this is a feature that belongs in a public module that's used by others. The code will only ever make sense in your use-case, and that will confuse people who try to understand how the module works and what it does. I'd like it to remain simple, following the does-one-thing-well principle. But you can always just fork it and go nuts. :-)