[debian-mysql] conf files decoupling (Re: On IRC?)

[Otto Kekäläinen]

Hello!

2015-02-05 13:19 GMT+02:00 Robie Basak <robie.basak at canonical.com>:
> On Wed, Feb 04, 2015 at 07:30:14PM +0200, Otto Kekäläinen wrote:
>> 2015-02-04 14:54 GMT+02:00 Robie Basak <robie.basak at canonical.com>:
>> > On Tue, Feb 03, 2015 at 11:27:58PM +0200, Otto Kekäläinen wrote:
>> >> Don't look at that, see
>> >> https://github.com/ottok/mariadb-10.0/commit/d42fba6d08ee76b517655af7ebcd89693da39ea9
>> >> instead.
>> >
>> > Thanks. This looks good. A couple of comments:
>> >
>> > Can you please also include /etc/mysql/conf.d/ in your
>> > /etc/mysql/mariadb.cnf? Then packages supplying the client can drop
>> > client configuration into there, and so can the user. It'll also mean
>> > that any previous customised configuration will be carried forward
>> > unaltered.
>>
>> Your example https://github.com/basak/debian-mysql/blob/560c9c2609cbbb1d92b944428371ffb20a6608b9/debian/additions/mysql.cnf
>> only includes /etc/mysql/mysql.conf.d not /etc/mysql/conf.d/. The
>> plain conf.d is only called from the my.cnf.fallback
>
> My mistake. I'll fix this.

I don't see any new commits in
https://github.com/basak/debian-mysql/commits/master in February, do
you do your fixes in some other location?

>> Are you sure the MariaDB package should include both mariadb.conf.d
>> and conf.d? Isn't the point to create separation in the configs and
>> not to permanently keep stuff in conf.d that all versions might read?
>> Would it be better to do a one-time "cp -rf conf.d/* mariadb.conf.d"
>> instead if we want to carry over old configs?
>
> I think that the plan for carrying the configuration forwards must be
> the same for all variants, to avoid complexity. Otherwise a user might
> upgrade one variant and then switch to another and then the packaging
> will fail to keep up.
>
> It seems easiest to me to just leave conf.d/* alone, and include it.

Ok, so to recap the policy we are now implementing:
1. Each variant registers their own /etc/mysql/my.cnf ->
/etc/mysql/<variant>.cnf
2. The /etc/mysql/<variant>.cnf file can basically be almost empty but
it makes sure that the configs in /etc/mysqlconf.d/*.cnf and
/etc/mysql/<variant>.conf.d/*.cnf are loaded
3. Common and shared configs can continue to live in /etc/mysql/conf.d
4. Variant specific configs will live in /etc/mysql/<variant>.conf.d
5. If the confs in /etc/mysql/conf.d/*.cnf and
/etc/mysql/<variant>.conf.d/*.cnf conflict, the per-variant files are
read later and thus override any /conf.d/*.cnf definitions.


>> What do you mean "client can drop"? I've now put all MariaDB confs in
>> mariadb.conf.d, both client and server.
>
> I mean that packaging (any package, any variant, even packages that
> aren't MySQL variants such as tools) can then assume that placing
> configuration files in conf.d/ will always work.
>
> It also gives users a place to put configuration that they want to
> retain even when switching variants. This is effectively what they've
> indicated by putting something in conf.d/ prior to this upgrade, and so
> it's convenient that we maintain the same semantics afterwards too. This
> makes it easier to not break users' customized configurations on the
> upgrade, or in the future when switching variants.

OK. My recap above should reflect this.

>> Ok, I removed the mv command and replaced with a simple echo notifying
>> the user to check the config path.
>
> This is better, but doesn't it still cause a problem if the new
> mariadb-server-10.0 is configured before the new mysql-common package?
> A straightforward upgrade is the common case, and if you don't enforce
> postinst ordering with the Depends then some number of these could
> configure the other way. So it seems to me that a large proportion of
> users will upgrade and then be without a symlink at all just because
> dpkg happened to configure mariadb-server-10.0 first.

Hmm.. I should pin the mysql-common to be preconfigured first because
a missing/old my.cnf would anyway break things.

> IMHO, the only sensible way to do this is how I've done it in Oracle and
> Percona - to depend on the newer mysql-common, and just call
> configure-symlinks. I don't see any disadvantage to not doing this - we
> just need to make sure that we upload the new mysql-common first, which
> we can make sure to do.
>
> (In Ubuntu, variants doing this would be held in vivid-proposed until
> the newer mysql-common package is available anyway. I presume Debian
> would hold things in unstable and not migrate to testing until this
> happens also?)

I like the idea of having a bit of backwards compatibility and at the
same time cater for new features (the goal here was to allow for per
variant configs), so I'll try to think a bit more if I come up with an
perfect solution here.

> OK. We're running out of time now though - we have only two weeks to
> feature freeze in Ubuntu now. I understand that you're busy, but I think
> I have to start uploading things to Ubuntu now in order to make Vivid.
> This might involve me having to diverge mariadb-10.0 in Ubuntu. I'll try
> to minimize impact which a view to syncing back in the future as much as
> I can.

OK


-- 
Check out our blog at http://seravo.fi/blog
and follow @ottokekalainen