support modifying config

[Edward Hope-Morley]

Not currently possible to change writeback_percent or sequential_cutoff but would be nice to be able to do so.

[Dan Hill (hillpd)]

This feature was requested in sf#00254581.

[Drew Freiberger (afreiberger)]

@hillpd,

https://git.launchpad.net/~hillpd/charm-bcache-tuning/commit/?id=be250e9be87b860257a8020b090737294f0a91c1

This code LGTM, though I think that defaulting to writeback may be more appropriate for our general workload. Doesn't make sense to default to writeback_percent of 10 without enabling writeback mode.

I've submitted your branch for MR and made this note there.

[Trent Lloyd (lathiat)]

I agree that writethrough is a bad default, but, that option should just be removed from this charm because cache_mode is one of the few settings the bcache actually persists on its own to the superblock. So if you set it, it will stay set after reboot (unlike writeback_percent, sequential_cutoff, readahead, congestion, etc)

Otherwise looks good to me.

[Drew Freiberger (afreiberger)]

While I agree with your sentiment that once set, the setting will persist in the bcache device, however, the reason we deploy this charm is to capture our very opinionated best practices for performance on openstack environments as default configuration.

While writethrough is the safest setting and results in the least potential data-loss, writeback is what's needed for ceph to have usable performance as general purpose virtual machine root disk backing device.

I'd be okay with this charm not managing bcache settings if writeback were the default when creating bcaches with "make-bcache -B" or defining them in MAAS via cli or FCE tools.

[Drew Freiberger (afreiberger)]

Additional reasoning for my comment on writeback being the default is that this charm embodies the best practice settings suggested by the openstack product engineering team who are defining bcache modes for ceph OSD backing devices, nova ephemeral mounts, and API service/mysql container filesystems.

We want this charm to continually standardize bcache configurations per charm configuration, smoothing over operational mistakes when manually configuring bcaches, no matter where those settings are made.

If we do choose to set the defaults to unmanaged, then we need to ensure the foundation cloud templates start integrating this charm with the openstack opinionated defaults if this charm will not be carrying over those opinionated defaults into the future.

[Dan Hill (hillpd)]

The charm documentation doesn't mention ceph or even openstack. This charm is public, and my concern is that it may be used outside of bootstack. I am not comfortable signing off on a change that would silently modify cache-mode to a setting that introduces data loss risk, as this may take other users by surprise.

I agree that the use cases you outline are valid best practices for write-back that either mitigate or intentionally accept the risk of data loss. This intent needs to be captured on the charm's landing page.

Today the cache-mode setting is not modified by the charm. This MP allows the user to configure cache-mode but sets a default of "unmanaged" to ensure that the user makes an active choice in enabling write-back.

In both cases, the user must configure write-back.

> We want this charm to continually standardize bcache configurations per charm configuration, smoothing over operational mistakes when manually configuring bcaches, no matter where those settings are made.

How about accepting this MP and opening a bug to modify the default to write-back? To avoid surprising any users and/or causing them issues, we need to first issue a notice that the new option has been introduced while the default has not been changed, with an intention to change it for the next version. That gives any other consumers of the charm a chance to learn of the change and prepare for it.

[Xav Paice (xavpaice)]

Change available at cs:~bootstack-charmers-next/bcache-tuning-3 until release.