sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Munteanu <romb...@apache.org>
Subject Re: [discuss] Migrating the Sling Starter to the Feature Model
Date Mon, 11 May 2020 21:07:32 GMT
On Mon, 2020-05-11 at 13:43 -0700, Andreas Schaefer wrote:
> Hi Robert
> 
> I think there is a misconception what the Kickstart is. Here is my
> rundown:
> 
> - Provides a Sling FM
> - Creates a Control Thread
> - Offers Sling specific CLI options and converts them to Sling
> properties
> - Launches Sling through the Feature Launcher
> - Provides the ability to access Sling running in another thread
> 
> Because of the current situation it also does that:
> 
> - Provides a mean to convert Sling PMs to FMs
> - Aggregates these FMs

Ack.

> 
> That said this is just temporary and should go away as soon as Sling
> is Feature Model-yfied.
> 
> I am not sure how Sling is used in production environments (beside
> Peregrine) but I assume customers use Sling Start one way the other
> even if they create their own PM(s) to launch it with the Starter
> (Peregrine does that).
> The Kickstart can take a custom Sling FM (override the packaged one)
> as well as custom project FM(s).
> 
> As a user I do not want to hunt down the properties on how to launch
> Sling but rather have an option in a Start (here Kickstart).
> Instead of “-Dsling.port=8080” something like “-p 8080” would be
> better especially because the Kickstart expose these options with the
> “—help”” option.
> 
> The Kickstart project does not compete or shadow any of the feature
> tooling but rather leverages them. In addition support for Composite
> Nodestores is something the Feature Launcher cannot do and would
> require scripts to run which are harder to manage for an admin.

Right.

I get the feeling that I am missing something, as I think we write the
same things but don't necessarily agree :-)

Let me try and rephrase my draft proposal in a very compact manner,
let's see where the difference lie.

1. The feature model provides tooling for assembling and validating
feature model files.

2. Kickstart is a convenient, featureful high-level launcher, and some
(most?) users will like to use that for starting Sling.

3. The feature model launcher is a pure OSGi launcher for users that
either desire to not be tied to the kickstart or do not have an use for
the additional features of the kickstart.

Does that match how you see things? If not, I'd love to understand
where things don't align.

Thanks,
Robert
> 
> Cheers - Andy
> 
> > On May 11, 2020, at 1:05 PM, Robert Munteanu <rombert@apache.org>
> > wrote:
> > 
> > Hi Andy,
> > 
> > On Mon, 2020-05-11 at 09:50 -0700, Andreas Schaefer wrote:
> > > Hi Robert
> > > 
> > > Thanks for the nice rundown here but I think it is slightly
> > > "behind
> > > the curve”.
> > > 
> > > The current Kickstart project will:
> > > - take the Provisioning Model (PM) files and convert them into a
> > > Feature Model (FM) files
> > > - aggregates the FM files into a single FM (feature-sling12.json)
> > > - launches the Sling with the Feature Launcher with the feature-
> > > sling12.json
> > > - has the ability to launch Sling12 with a FAR file if provided
> > > - run Sling in the background as a service (if needed) (-s
> > > option)
> > > - can obtains status and stop a launched instance
> > > - add additional FMs (custom projects) to the launch (-af option)
> > 
> > Right, the kickstart project is quite featureful, and I personally
> > see
> > it as a 'batteries-included' launcher, which goes beyond what the
> > 'stock' feature launcher offers. There are scenarios where
> > kickstart is
> > better suited, and scenarios where the additional complexity is not
> > needed.
> > 
> > (Hindsight being 20/20 and all, I'd have suggested 'thinpad' as the
> > name for it, as I currently see it as a replacement for the
> > launchpad,
> > but thinner).
> > 
> > 
> > > Right now this is only tested for oak_tar but there it works like
> > > a
> > > charm.
> > > 
> > > Down the road I would like the Kickstart to be able to launch
> > > Sling
> > > with a composite node store (read-only libs, writable content)
> > > w/o
> > > any user interaction.
> > > 
> > > From my point of view the coding part of Phase 1 and 2 is mostly
> > > done.
> > > 
> > > These are the next step I see:
> > > - add support for analyzer (when I created Kickstart the analyzer
> > > was
> > > not working properly so I took it out)
> > > - test Kickstart with oak_mongo
> > > - add composite node-store support to Kickstart
> > > - migrate Sling Modules to creating FMs
> > > - aggregating Sling based on FMs directly (no PMs involved)
> > > - lots and lots of documentation
> > 
> > Here is where I see an overlap with the feature model tooling. We
> > have
> > analysers, aggregators, launchers, etc in the feature model as
> > standalone applications, java libraries and Maven plug-ins.
> > 
> > I think it makes sense to have each tool with its own well-defined
> > purpose. I definitely see the value in having a full-fledged
> > replacement for the launchapd - that is the kickstart. 
> > 
> > However, it would be confusing to have the same functionality
> > defined
> > in both the feature and the kickstart plugins, and while I don't
> > claim
> > to be the hardest person to confuse :-) I think that this confusion
> > would apply to our users as well.
> > 
> > I believe that the kickstart should focus on being an advanced
> > launcher, while the feature tooling providers the core services.
> > 
> > This is why I suggested that we adopt the kickstart as a part of
> > the
> > feature build - the rest should be supported by the other feature-
> > based 
> > tooling.
> > 
> > > In my view each Sling Module should create their own FM that
> > > includes
> > > all the configurations (Service User Mappings etc) and the
> > > repoinit
> > > it needs to run properly. 
> > 
> > (snip)
> > 
> > I don't necessarily disagree, but let's please split this off into
> > a
> > different discussion. I think the 'in-place' conversion of the
> > Starter
> > is a large enough topic for now.
> > 
> > Thanks,
> > Robert


Mime
View raw message