Hi Andreas, deprecated but do nothing is IMHO a BC break. A deprecation is only useful if it does it's behavior (but overwritten by the new configuration) until it is removed.
Sadly revisions are not a useful versioning scheme. Would be cool if juju can adapt semantic versioning, so a charm can deprecate options, use it in 1.x versions and remove it in 2.x versions. Juju would not update a charm over a major version until it is told so. Andreas Hasenack <andr...@canonical.com> schrieb am Do., 14. Jan. 2016 um 20:01 Uhr: > TL;DR > Should charms a) remove deprecated options; b) accept them but do nothing > (the case below); c) accept them for a while, log a warning, then remove; > d) ? > > Hi, > > Recently the postgresql charm deprecated several config options. For > example: > > max_connections: > default: 100 > type: int > description: > > DEPRECATED. Use extra_pg_conf. > Maximum number of connections to allow to the PG database > > The option still exists and can be set, but does nothing. The service will > get whatever is set in the new extra_pg_conf option, which happens to be > 100. > > I believe the intent of this behaviour was to not break the deployment of > the charm using existing configuration files. But instead it introduces a > subtle breakage: my DB can now only handle 100 connections, whereas before > it was (in my case) 500. The deployment works, but the system doesn't > behave as before and eventually breaks under use. That lead to some > debugging until this was found: > > psycopg2.OperationalError: FATAL: remaining connection slots are reserved > for non-replication superuser connections > > Other deprecated options have a more explicit warning: > > performance_tuning: > default: "Mixed" > type: string > description: > > DEPRECATED AND IGNORED. The pgtune project has been abandoned > and the packages dropped from Debian and Ubuntu. The charm > still performs some basic tuning, which users can tweak using > extra_pg_config. > > In this specific postgresql case, looks like all (I just tested two, btw) > deprecated options should have been marked with the extra "... AND IGNORED" > text. But then again, is it worth it to silently accept them and do > nothing, thereby introducing subtle run-time failures? > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
