See attachments for current thinking - I'd want the tuning of the devices to be independent of the charm code, so having a systemd unit that runs after block device udev processing seems to make sense to me.
With that in mind, this might be nicer done as a subordinate charm; this will support converged and split deployments of nova-compute/swift/ceph-osd better, and we can drop it completely if MAAS/curtin grows support for configuring bcache params as part of installation (which could give per-device granularity to tuning).
See attachments for current thinking - I'd want the tuning of the devices to be independent of the charm code, so having a systemd unit that runs after block device udev processing seems to make sense to me.
With that in mind, this might be nicer done as a subordinate charm; this will support converged and split deployments of nova-compute/ swift/ceph- osd better, and we can drop it completely if MAAS/curtin grows support for configuring bcache params as part of installation (which could give per-device granularity to tuning).