[Thinlinc-technical] Migrate configuration during ThinLinc upgrade

[Martin Leiser]

Am 10. Dezember 2015 14:41:36 MEZ, schrieb Peter Astrand <astrand at cendio.se>:
>
>Hi. We are thinking about improving the configuration handling during a
>
>ThinLinc upgrade, and wants to share our thoughts with you, in order to
>
>get some feedback.
>
>As you probably know, ThinLinc uses the "Hiveconf" configuration
>system, 
>where parameter/value pairs are stored in an abstract folder-like 
>namespace. In practice, parameters are stored in text files below 
>/opt/thinlinc/etc/conf.d/. These files are marked as configuration
>files, 
>in order to get some special attention by the package managers
>(RPM/DPKG). 
>

Yaml is nice too,
but hiveconf is fine as well....

What helps a lot are good examples contained in default configurations.

>
>The different options we are discussing now are:
>
>1) Use the "new" files from the updated packages. This is how it works 
>today, if you do not do anything between running install-server and 
>tl-setup. This option has the following properties:
>
>Preserves existing configuration?: NO
>Conf. guaranteed to work with new version? YES
>Default values?: NEW
>Comments and file structure?: NEW
>New parameters visible?: YES
>

Hmmm:

Why not shipping the default configuration files with git?
Containing all the default configuration file you ever shipped.

Commit the custumers version in the beginning of the upgrade in a customer branch.

Then merge the new version with the customer branch.

You might get merge conflicts using the default strategie,
you may or should fall back to the ours or yours strategie...

You got the Idea?
Merging is the business of version control systems like git.
Use them.

>
>2) Use the "old" files. The .rpmsave/.dpkg-old files are simply renamed
>
>into place.
>
>Preserves existing configuration?: YES
>Conf. guaranteed to work with new version? NO
>Default values?: OLD
>Comments and file structure?: OLD
>New parameters visible?: NO
>

This is the customer branch.

>
>3) Base the configuration on the new files, but import values from the
>old 
>file. I have written a tool that basically loops over the parameters in
>
>all .rpmsave/.dpkg-old and "imports" the parameter values into the 
>active configuration (which is based on the new files). This means that
>
>the perceived configuration (say, for end users) is the same as before 
>the upgrade.
>
>Preserves existing configuration?: YES
>Conf. guaranteed to work with new version? NO
>Default values?: OLD
>Comments and file structure?: NEW
>New parameters visible?: YES
>
This is the "merged" branch in git terms.


>
>I'm personally quite fond of solution 3 (migrate), so my initial idea
>was 
>to have that as the default option in tl-setup, but also make it
>possible 
>to opt out for such a migration, which means solution 1 (new files) 
>instead (since that is what the package manager gives you). It would
>also 
>be possible to get solution 2 (old files) by exiting tl-setup and, say,
>
>manually renaming files.

Agree, except for the tooling.

Using git the customer gets all of them, simply by checking out different branches after the upgrade.

If you choose proper defaults and good defaults
merge conflicts should pop up exactly in the critical case:
Where you changed the defaults and the customer the value.

The customer need not know about git to make an upgrade.
But if she does, she gets more transparency and control
plus a nice vehicle to control and document her configuration file changes.

Sound like overkill? May be. May be not....

>
>However, we are considering other alternatives as well. This includes
>but 
>is not limited to: not having any default, providing an option for 
>solution 2 (old files) as well etc. Or perhaps the current
>implementation 
>is sufficient?
>

Giving more details and pointing to critical and potentially dangerous changes is important.

Yours Martin Leiser

>Since it's somewhat difficult to describe all this in text, I'm
>attaching 
>a screenshot of what it could look like.
>
>What do you think? Any feedback is appreciated.
>
>Regards, 
>---
>Peter Astrand		ThinLinc Chief Developer
>Cendio AB		https://cendio.com
>Teknikringen 8		https://twitter.com/ThinLinc
>583 30 Linkoping	https://facebook.com/ThinLinc
>Phone: +46-13-214600	https://google.com/+CendioThinLinc
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Thinlinc-technical mailing list
>Thinlinc-technical at lists.cendio.se
>Manage your subscription:
>http://lists.cendio.se/mailman/listinfo/thinlinc-technical