Feature request: functionality to better support image build use cases

[enunes]

We have a use case for tuned which involves generating images with osbuild, where tuned will only be run at the target but may not be available in the builder machine. For simpler profiles, one solution is to just create the profile name files in /etc/tuned/active_profile (there is already an osbuild stage for tuned), but this does not cover all use cases. For example some profiles rely on kernel parameters, which are currently not trivial to get "offline" and will only be generated after the first boot at the target, also requiring a reboot. It would be nice to be able to know those beforehand as well as skipping the need for a first reboot of the target.

A workaround for this could be to run tuned-adm at image build time to generate the boot commands, but there are also currently challenges for that. If tuned-adm is run without any sort of isolation it will always look for paths like /etc which will be of the host. It would be nice to be able to pass something like a directory base path where it will look for $BASEDIR/etc and $BASEDIR/usr/lib/tuned so any profiles I create for the target can be found.

This use case considers tuned-adm utilization without the tuned daemon. Having to run the daemon in the builder system is also undesirable (and even if the builder system is already running tuned, it should not be affected by building a target image). In the target it may or may not be desired to run the daemon but that should be independent.

Finally, for this sort of images, grub is not always present. Some of the current setup for the kernel parameters seem to assume that grub is present by default.

From some local experimentation, I think these are the features that could make this possible:

• Ability to pass a base directory path to tuned-adm where it will look for the configs and profiles relative to that.
• Have a mode that will just run the tuned logic and create the full profile configuration (one very important thing here is to generate the kernel cmdline). Some profiles (e.g. realtime) compose them from including other profiles (e.g. network-latency) which add their own cmdline which makes it non-trivial to just try to parse them from any tuned file.
• Related to the above, reduce the dependency on grub. Some of the systems for this use case don't run grub at all. In these cases the offline build will take the arguments from e.g. /etc/kernel/cmdline to create the boot files. So if tuned will put those arguments in the grubenv this is not relevant to these systems at all.
• Do a "dry-run" which will not attempt to set any sysctl or sysfs settings to not affect the host, as well as not attempt to talk to the host daemon and not attempt to change the host profile. (It is currently possible to partially work around this with a profile overlay which will disable sysctl and sysfs, but it would be nice to have a cleaner mode for this).

I'm not sure how much of this is feasible, any thoughts about supporting this feature? If necessary I can file separate issues but this one can be used to discuss the feasibility of this, or if some part of this is already supported but I missed it.

Thanks!

[yarda]

From some local experimentation, I think these are the features that could make this possible:

* Ability to pass a base directory path to tuned-adm where it will look for the configs and profiles relative to that.

This is handled by daemon (even if running in no-daemon mode, then the daemon does all the work and exits). The path for the daemon can be configured in /etc/tuned/tuned-main.conf:

profile_dirs = /usr/lib/tuned,/etc/tuned

* Have a mode that will just run the tuned logic and create the full profile configuration (one very important thing here is to generate the kernel cmdline). Some profiles (e.g. realtime) compose them from including other profiles (e.g. network-latency) which add their own cmdline which makes it non-trivial to just try to parse them from any tuned file.

This could be probably covered by the simulate/dry-run option RFE (not yet implemented) and the dump feature (#625, not yet finished).

* Related to the above, reduce the dependency on grub. Some of the systems for this use case don't run grub at all. In these cases the offline build will take the arguments from e.g. `/etc/kernel/cmdline` to create the boot files. So if tuned will put those arguments in the grubenv this is not relevant to these systems at all.

We support multiple boot loaders. We could also put the boot arguments into /etc/kernel/cmdline.

* Do a "dry-run" which will not attempt to set any sysctl or sysfs settings to not affect the host, as well as not attempt to talk to the host daemon and not attempt to change the host profile. (It is currently possible to partially work around this with a profile overlay which will disable sysctl and sysfs, but it would be nice to have a cleaner mode for this).

This could be covered by the simulate/dry-run option RFE mentioned above.

@thozza do you have any comments? (IIRC you do/did something similar).

[enunes]

This is handled by daemon (even if running in no-daemon mode, then the daemon does all the work and exits). The path for the daemon can be configured in /etc/tuned/tuned-main.conf

But this would rely on /etc/tuned/tuned-main.conf from the host so I would still need to change the configuration of the builder machine (and have the daemon installed in the host), right? So that way would not be ideal, since we don't want to touch the builder host configuration. From the point of view of this feature, better would be to pass an argument to tuned-adm for it with a base path for the entire configuration (including the path for .../etc/tuned/tuned-main.conf.