Hi, On Sat, Nov 16, 2013 at 10:58 AM, Ian Boston <i...@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