Right, 80% may not make a lot of sense actually, depending on the scenario. Unfortunately, it is an established default, and I think we would need to proceed carefully.
I'm all for sensible defaults. I do think we need to take a hard look at the potential impact of a default charm config option value change, any time that is considered. My main concern is that, in changing a default value, we risk breaking existing users. As long as we give advanced notice, eta, updated docs, release notes, etc., I think it should be a completely reasonable thing to pursue a default value change.
That one is easy enough to identify and fix. We just need to take the time to evaluate, discuss, identify the risks and the things-to-do, then do them, if that is the consensus.
Right, 80% may not make a lot of sense actually, depending on the scenario. Unfortunately, it is an established default, and I think we would need to proceed carefully.
I'm all for sensible defaults. I do think we need to take a hard look at the potential impact of a default charm config option value change, any time that is considered. My main concern is that, in changing a default value, we risk breaking existing users. As long as we give advanced notice, eta, updated docs, release notes, etc., I think it should be a completely reasonable thing to pursue a default value change.
We would also need to take a look at the bundles in the charm store to identify and adjust any which rely on the established default value. For example... ;-) and I'm not at all biased: /jujucharms. com/openstack- base/36 (https:/ /api.jujucharms .com/charmstore /v4/bundle/ openstack- base-36/ archive/ bundle. yaml)
https:/
That one is easy enough to identify and fix. We just need to take the time to evaluate, discuss, identify the risks and the things-to-do, then do them, if that is the consensus.