When using only governor, the charm adds a grub config

[Nicolas Pochet]

When deploying a simple bundle like:
series: bionic
applications:
  ubuntu:
    charm: cs:ubuntu
    num_units: 1
  sysconfig:
    charm: cs:~canonical-bootstack/sysconfig-8
    options:
      governor: 'performance'
relations:
  - - ubuntu:juju-info
    - sysconfig:juju-info

We see the following in juju status
Model Controller Cloud/Region Version SLA Timestamp
sysconfig maas maas 2.6.9 unsupported 07:42:13Z

App Version Status Scale Charm Store Rev OS Notes
sysconfig active 1 sysconfig jujucharms 8 ubuntu
ubuntu 18.04 active 1 ubuntu jujucharms 12 ubuntu

Unit Workload Agent Machine Public address Ports Message
ubuntu/0* active idle 0 172.27.12.141 ready
  sysconfig/0* active idle 172.27.12.141 reboot required. Changes in: /etc/systemd/system.conf, /etc/default/grub.d/90-sysconfig.cfg

Machine State DNS Inst id Series AZ Message
0 started 172.27.12.141 node02 bionic default Deployed

In the machine, we can see that there's a new /etc/default/grub.d/90-sysconfig.cfg file.

This is due to the fact that during the first config-changed hook, all flags are set to their default value: https://git.launchpad.net/charm-sysconfig/tree/src/reactive/sysconfig.py#n82
Therefore, it will run the update_grub_file function: https://git.launchpad.net/charm-sysconfig/tree/src/lib/lib_sysconfig.py#n226
In this function, when getting the enable_pti property (as the config option enable-pti is not set), it will set pti_off in the context to True.
A grub file will then be rendered.

[Nicolas Pochet (npochet)]

After a bit more of investigation, it seems that the install_sysconfig() function call update_grub_file without any condition: https://git.launchpad.net/charm-sysconfig/tree/src/reactive/sysconfig.py#n55

[Alvaro Uria (aluria)]

* Reviewed MP
* suggested a different approach (initialize checksums of managed configuration files on the reactive entry function so any_file_changed can solely be called to verify if an update is needed)
* triaged this bug as "Low" because the Juju description can be reset to "ready" by running the "clear-notification" action

[Vern Hart (vern)]

Running the clear-notification action clears the block and changes the status message to "ready" but within a few minutes, the charm returns to blocked requesting a reboot. There doesn't appear to be a way to resolve this without rebooting, which is a very heavy-handed solution.

[Marcelo Subtil Marcal (msmarcal)]

The charm is not just adding the GRUB configuration but also erasing the kernel options MAAS configured.

/etc/default/grub.d/90-sysconfig.cfg rendered file contains:

```
# Juju generated file - do not edit manually

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

# Evaluate grub-config-flags first, in case it uses $GRUB_CMDLINE_LINUX_DEFAULT.
# However, if grub-config-flags is not specified, ignore that (current behavior.)
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT console=ttyS0,115200 console=tty0"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
GRUB_TERMINAL=serial
```

Also, it adds "console=ttyS0,115200 console=tty0" to the options (which has already been added by MAAS)

IMHO, the template shouldn't set GRUB_CMDLINE_LINUX_DEFAULT="" even if the grub-config-flags option is not set. (https://git.launchpad.net/charm-sysconfig/tree/src/templates/grub.j2#n12)

[Nobuto Murata (nobuto)]

This is going to be handled in:
https://bugs.launchpad.net/charm-sysconfig/+bug/2012581