Deprecating charm config options: postgresql case

[Patrik Karisch]

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 <andreas at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160114/c0b0502d/attachment.html>