You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/04/23 12:41:38 UTC

Re: Is Sling DevOps and Cluster friendly?

Hi,

On Sat, Nov 16, 2013 at 10:58 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...the repository under Sling would have to be
> reserved for data generated by the application or initial content,
> whilst application code and configuration is kept on the filesystem,
> so that a running instance could be upgraded entirely on the
> filesystem by configuration management and versioned in a single
> atomic operation...

FYI, in case anyone's interested we've been doing some experiments
along these lines with my intern Artyom. The experiments themselves
are at [1] and we'll be using the work-in-progress contrib/crankstart
module to continue experimenting.

This experimental crankstart launcher fully defines a Sling instance
in a text file like [2], which is useful in a devops/continuous
deployment context, especially if Sling instances can be considered
throwaway - in our experiments we never change the "configuration" of
a Sling instance (in a wide sense, "configuration" including bundles,
scripts, OSGi configs etc) but spin up and switch to new Sling
instances when the config changes. Careful coordination with the HTTP
front-end (mod_proxy or similar) allows for the switch from one
configuration to the next to be atomic, as seen from the outside.

This is all still very experimental...just wanted to share the rough
ideas in case people are interested in contributing or playing with
that stuff.

-Bertrand

[1] https://github.com/bdelacretaz/sling-devops-experiments (and
Artyom's fork might be more current,
https://github.com/ArtyomStetsenko/sling-devops-experiments)

[2] http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/sling.crank.txt