Re: Proposal: Versioned Definitions - WAS Re: First thoughts on s6

From: post-sysv <boycottsystemd_at_openmailbox.org>
Date: Thu, 25 Jun 2015 17:28:25 -0400

I'm honestly struggling to think of a practical use case for this,
though I may be lacking sufficient context.

The case of a daemon breaking semantics of existing options is quite
seldom seen, and just a bad practice for reasons of maintaining least
surprise and compatibility. Even when major versions are bumped, it's
rare to see such a thing.

Now when new options are added, old configurations still tend to run the
same (unless it's a scenario of this flag now needs that flag set in
unison, which again is a breaking change).

By all means just version and update the runscript. Symlink farms are
always frustrating to deal with. It didn't work well for sysvinit at all.

On 06/25/2015 02:40 PM, Avery Payne wrote:
>
>> With yesterday's mention of the idea of a clearinghouse, the concept
>> that
>> daemon options need to be versioned has been in the back of my head.
>> Here
>> is an idea: versioned definitions. A crude example:
>>
>> /etc/sv/sshd/envdir/DAEMON -> /etc/sv/sshd/envdir/current/DAEMON
>> /etc/sv/sshd/envdir/DAEMONOPTS -> /etc/sv/sshd/envdir/current/DAEMONOPTS
>> /etc/sv/sshd/envdir/current-> /etc/sv/sshd/versions/v3
>> /etc/sv/sshd/envdir/versions/v3/DAEMON
>> /etc/sv/sshd/envdir/versions/v3/DAEMONOPTS
>> /etc/sv/sshd/envdir/versions/v2/DAEMON
>> /etc/sv/sshd/envdir/versions/v2/DAEMONOPTS
>>
> So this was the seed of an idea that borrowed heavily from elsewhere.
>
> The problem:
> As software daemons mature, they acquire new options and change their
> behavior. Because a service definition is tied to launching a version
> of a daemon, that means on any upgrade, the definition has the
> possibility of breakage due to those changes.
>
> The concept:
> Settings for daemons should be versioned so that, for a given release
> of a daemon, the "correct" options and settings will be used.
>
> The proposal:
> I've left the original rough idea at the top of the message for
> comparison only. It is not the proposal.
>
> The idea would be that, for a given definition, a ./version directory
> would exist that would house the version-specific information. A soft
> link that normally represents the settings to be used would then point
> to the correct version. A sample layout appears below.
>
> /etc/svcdef/sshd/env -> ../version/3.81
> /etc/svcdef/sshd/version/3.81/
> /etc/svcdef/sshd/version/3.81/DAEMON
> /etc/svcdef/sshd/version/3.81/DAEMONOPTS
> /etc/svcdef/sshd/version/3.81/PRELAUCH
> /etc/svcdef/sshd/version/3.8/
> /etc/svcdef/sshd/version/3.8/DAEMON
> /etc/svcdef/sshd/version/3.8/DAEMONOPTS
> /etc/svcdef/sshd/version/3.8/PRELAUNCH
>
> While the definition names are specific to supervision-scripts, the
> layout is not, and could conceivably hold other files and data in
> them; for instance, Toki's supervision framework could store shell
> script settings there instead of envdir files, and the soft link would
> point to the specific script. In this manner, we can define where and
> what is stored without caring about the how.
>
> Advantages:
> * Solves the version-breakage problem.
> * The format is data-content-agnostic, it only requires that storage
> be in a file.
> * The format can be universally supported with all existing
> supervision frameworks without a naming conflict.
> * The format can be installed into legacy supervision arrangements
> without breaking the environment.
> * The format is entirely optional. The proposal is to recognize this
> as a common practice.
> * Allows the administrator the possibility of creating custom settings
> instead of using default or system-supplied settings.
> * Allows the administrator the possibility of rolling back to a prior
> version without a loss of settings.
>
> Potential issues:
> * It requires a filesystem that supports soft links.
> * Storage requirements will grow with the number of versioned
> definitions.
> * There is no guarantee that the data format will be consistent.
> * For slower systems, some additional disk activity will be required.
> For most modern systems this isn't an issue, but for legacy systems it
> may have a slight impact.
> * There may be some suite of programs that will conflict with this
> arrangement.
>
Received on Thu Jun 25 2015 - 21:28:25 UTC