On 09/11/2017 07:34 AM, Peter Krempa wrote:
On Wed, Sep 06, 2017 at 15:24:18 -0400, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1464313
As it turns out, the on-disk config file (e.g. not the stateDir file) needs to be updated when --override is provided since it's possible and highly probable that the def->source.format has been adjusted and could cause a future start after perhaps a libvirtd restart to have the older format from a define operation from the backend.
So in the 2 places where it's possible a write would be needed (create after define and build), let's perform a check and do the save/write operation on the configFile if it's necessary.
I don't think this is correct. If you use the "create" API with a custom XML this should not in any way touch the persistent config of the pool, similarly as we do with VMs. The provided XML may describe a completely different storage pool and using the 'create' API should not overwrite anything stored persistently.
If a user messes up the storage state via the live config, he needs to fix everything by themselves.
This would just overwrite persistent config which is not desired.
NACK
To both Create and Build or just Create? Not sure I can visualize the Create path noted above, but it's still early in the morning with not enough coffee yet. Still the logic to decide to write out the config file is gated on whether the caller wanted overwrite (via VIR_STORAGE_POOL_BUILD_OVERWRITE flag being provided), but unlike VM's there's no flags to indicate whether we're "active" or "inactive". So if someone has indicated to use the overwrite flag, then that says to me all bets are off and not only should the live config be updated (as it is), but the on disk config as well since the decision by the consumer is to overwrite. Without doing so we end up with an unusable pool the next time we start which is the crux of the bz. John