Hi Am 22.09.2014 um 15:47 schrieb Chetan Mehrotra <chetan.mehro...@gmail.com>:
> Hi Carsten, > > It would be good if following features can be supported in some form > > 1. Composition - Ability to include other slingstart file via various > url schemes file, http etc. Need to define how the included config > would be treated if collisions are found Not sure, whether really want this considering we want to have a concise description. Yet, having „source URLs“ for inclusion at least does not violate the idea of knowing where stuff comes from. > > 2. Property Interpolation - Ability to substitute property values via > system property, env variables [1] I think in this case we explicitly don’t want this: Also, this is not the same as the case for 12factor configuration: This is basically just a packing list to create a quick start. This is a build time task which should result in a quick start which can be used over and over again. As such, there is IMHO no need to depend on external variables. Actually, the goal is really to consolidate all the information in well-defined concise locations. Hence interpolate from external locations violates this principle and makes it unclear again, where a value comes from. > > 3. Mark config as global or local - By default if any config gets > updated at runtime it gets saved in repo and hence distributed across > various cluster nodes. In some case we need to avoid this write back While this really *is* an issue, it is unrelated to this project IIUIC, since again, this is about creating a quick start binary. Regards Felix > > Chetan Mehrotra > [1] http://12factor.net/config > > On Mon, Sep 22, 2014 at 5:26 PM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> I just renamed subsystem to deliverable. It's better to avoid the term >> subsystem as this might get confused with OSGi subsystem. This model can be >> used to define subsystems though of course. >> And I also renamed run mode to feature - and feature is tied to run modes. >> This entity is usually called feature in other systems >> >> Regards >> Carsten >> >> 2014-09-22 8:00 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: >> >>> Hi, >>> >>> >>> 2014-09-22 7:40 GMT+02:00 Bertrand Delacretaz <bdelacre...@apache.org>: >>> >>>> I agree, and the Crankstart launcher [1] is exactly about this. But you're >>>> right that agreeing on the *model* that describes the Sling instances is >>>> much more important than whatever code interprets this model. >>>> >>>> Right, and I also think the same goes for the describing language :) >>> >>> >>>> I much prefer structured text formats (either plain text or yaml) over XML >>>> for such things, as they're more friendly to hack and especially more >>>> diff-friendly which is very important in a devops view. But that's a >>>> detail >>>> in terms of defining the model. >>>> >>> >>> Right, if we have a model which also exactly describes how to merge we >>> have a solid foundation we can built on. >>> >>> >>>> How about creating some commented example definition files in svn (even if >>>> we have no code to run them so far), so we can look at each other's ideas >>>> and come up with a merged model of the good ideas on those files? >>>> >>>> Sure, just realized I forgot to commit those :) >>> >>> Here you go, it's the launchpad from last week, split up in three files: >>> >>> >>> http://svn.apache.org/repos/asf/sling/trunk/launchpad/slingstart/src/main/systems/ >>> >>> The slingstart maven launchpad plugin reads them on startup in >>> alphabetical order. >>> >>> Carsten >>> >>> >>>> For crankstart I can provide these files as examples that demonstrate the >>>> model features: >>>> >>>> >>>> http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/launcher/src/test/resources/launcher-test.crank.txt >>>> >>>> >>>> https://github.com/ArtyomStetsenko/sling-devops-experiments/blob/master/crankstart/sling-minion.crank.txt >>>> >>>> -Bertrand >>>> >>>>> >>>> [1] http://svn.apache.org/repos/asf/sling/trunk/contrib/crankstart/ >>>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >>> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org
