Hi Chetan,
2014-09-22 15:47 GMT+02:00 Chetan Mehrotra <[email protected]>: > 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 > > I think this shouldn't go into the model. The model defines how to merge two models, one being the main model and the other one merged into it. And the tooling defines how to find all models etc. Right now, if a model is merged into an existing one it overwrites on collisions. > 2. Property Interpolation - Ability to substitute property values via > system property, env variables [1] > As Felix said, we probably shouldn't do this. Depending on what you use to actually launch your instance, you might have some way to override it. > > 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 writeback > That's not part of the model and very specific to how we handle changes. Regards Carsten > > Chetan Mehrotra > [1] http://12factor.net/config > > On Mon, Sep 22, 2014 at 5:26 PM, Carsten Ziegeler <[email protected]> > 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 <[email protected]>: > > > >> Hi, > >> > >> > >> 2014-09-22 7:40 GMT+02:00 Bertrand Delacretaz <[email protected]>: > >> > >>> 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 > >> [email protected] > >> > > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > [email protected] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
