I think you may be onto something with using any_file_changed. While the intention is not to render a grub config if no change was detected from the charm, we could accomplish that with a data_changed query. The reason for this would be that kernel upgrades would change contents of grub files between config-changed runs, so we'd need to know if there were changes effected since last install/upgrade-charm/config-changed that would affect a change in config files before re-running a grub config.
I see your point about the if statements not catching all exceptions and need to update the logic there. Maybe incorporating a dict of those values and assess the impact via data_changed could make this a bit more readable and consistent. Likely evaluating all the configs except for reservation, and then evaluating the setting/changing of reservation with the exclusion of off/isolcpus.
If I get time, I'll add this as a stretch goal for addressing in 20.01 release.
I think you may be onto something with using any_file_changed. While the intention is not to render a grub config if no change was detected from the charm, we could accomplish that with a data_changed query. The reason for this would be that kernel upgrades would change contents of grub files between config-changed runs, so we'd need to know if there were changes effected since last install/ upgrade- charm/config- changed that would affect a change in config files before re-running a grub config.
I see your point about the if statements not catching all exceptions and need to update the logic there. Maybe incorporating a dict of those values and assess the impact via data_changed could make this a bit more readable and consistent. Likely evaluating all the configs except for reservation, and then evaluating the setting/changing of reservation with the exclusion of off/isolcpus.
If I get time, I'll add this as a stretch goal for addressing in 20.01 release.