You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2020/05/09 23:32:18 UTC
[discuss] Migrating the Sling Starter to the Feature Model
Hi,
I have drafted a wiki page about moving the starter to the feature
model.
https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model
I tried to sum up what I think we want to do, based on multiple mailing
list threads, and proposed what I think is a workable migration plan.
There are still some open points, and (maybe) some where I was too
optimistic. Comments are more than welcome, and please correct any
factual inaccuracies directly in the wiki page.
Thanks,
Robert
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
There is also a Maven Plugin for the Kickstart to launch it from within a POM file like running IT tests.
Like with the Kickstart Project the Plugin can launch FAR files as well if the used launcher is supporting it.
- Andy
> On May 11, 2020, at 9:50 AM, Andreas Schaefer <sc...@me.com.INVALID> 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 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
>
> 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. With that building Sling is a mere aggregation of the desired FMs with some minor overarching configurations and repoinit statements.
>
> - Each Sling Modules create its FM
> - Kickstart aggregates these Sling Module FMs into Sling FM
> or
> - Kickstart downloads the Sling FM from a release from a remote Maven repo
> - Kickstart launches that Sling FM
>
> The crucial part is that the resulting FM of a Module is added to Maven repository during a release so that users can download them from a remote Maven repo during the Kickstart aggregation without having to build each module on their own.
>
> - Andy
>
>> On May 9, 2020, at 4:32 PM, Robert Munteanu <ro...@apache.org> wrote:
>>
>> Hi,
>>
>> I have drafted a wiki page about moving the starter to the feature
>> model.
>>
>> https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model
>>
>> I tried to sum up what I think we want to do, based on multiple mailing
>> list threads, and proposed what I think is a workable migration plan.
>>
>> There are still some open points, and (maybe) some where I was too
>> optimistic. Comments are more than welcome, and please correct any
>> factual inaccuracies directly in the wiki page.
>>
>> Thanks,
>> Robert
>>
>
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2020-05-25 at 17:32 +0200, Robert Munteanu wrote:
> Top-posting as an attempt to sum up the next steps.
>
> I think we are more or less in agreement over what to do, and what
> each
> piece of the puzzle should do ( starter, ITs, feature model tooling,
> kickstart, etc).
>
> I would like to create more tasks to track the work that needs to be
> done. As part of that, I think SLING-8350 [1] needs to stay open as a
> top-level task, and I will create sub-tasks that represent individual
> units of work that anyone can pick up.
>
> Does that sound ok to everyone?
(snip)
I heard no objections, so I made SLING-8350 a top-level task, created
tasks for phase one and linked them from the wiki page. I will follow-
up shortly with a mail on users@sling regarding WAR support.
Thanks,
Robert
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Robert Munteanu <ro...@apache.org>.
Top-posting as an attempt to sum up the next steps.
I think we are more or less in agreement over what to do, and what each
piece of the puzzle should do ( starter, ITs, feature model tooling,
kickstart, etc).
I would like to create more tasks to track the work that needs to be
done. As part of that, I think SLING-8350 [1] needs to stay open as a
top-level task, and I will create sub-tasks that represent individual
units of work that anyone can pick up.
Does that sound ok to everyone?
Thanks,
Robert
[1]: https://issues.apache.org/jira/browse/SLING-8350
On Tue, 2020-05-12 at 18:26 +0200, Robert Munteanu wrote:
> On Mon, 2020-05-11 at 14:34 -0700, Andreas Schaefer wrote:
> > Yes, that sums it up pretty much.
>
> Great!
>
> > Also the Kickstart is replacing Launchpad more than the
> > SlingStarter
> > as the PMs go to the wayside in favor of the FMs that are then
> > managed outside of the Kickstart.
>
> Ack, fully agree on that.
>
> > With that said the testing of Sling FM should be done in a new
> > module
> > (Kickstart Testing?) than re-using Launchpad Testing but that seems
> > to be pretty straight forward as we can use Kickstart Plugin and
> > the
> > converted Sling FM.
>
> Not sure about that. The direction we're heading towards is that
> Launchpad testing should be going away and the test launcher folded
> in
> the starter. The reasoning is that integration tests in the same
> module
> have a much higher chance of catching regressions early.
>
> But then again I think we should keep this out of scope and focus on
> the conversion itself [1].
> > For me the basics on how to convert Sling to FMs from PMs and how
> > to
> > launch it is pretty much laid out. The next part is:
> >
> > - Create native Sling Module FMs
> > - Aggregate them into a Sling FM / FAR
> > - Adjust testing
> > - Write documentation
> > - Composite Nodestore
>
> +1 from me.
>
> Also the composite nodestore is a great feature to have set up. I
> would
> still like to focus on the feature model first, and then on the
> niceties :-)
>
> Regarding the feasibility of using the feature model tooling
> directly,
> I was able to tweak your great work from the kickstart and add an
> 'on-
> the-fly' conversion to the Sling Starter, so that the oak_tar
> aggregate
> is packaged. [2]
>
> Proof-of-concept to support the discussion, not necessarily the way
> we
> will go, so it's on a branch for now.
>
> Thanks,
> Robert
>
> [1]:
> https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model#MigratingtheSlingStartertotheFeatureModel-Outofscope
> [2]:
> https://github.com/apache/sling-org-apache-sling-starter/compare/feature/create-feature-aggregate?expand=1
> > - Andy
> >
> > > On May 11, 2020, at 2:07 PM, Robert Munteanu <ro...@apache.org>
> > > wrote:
> > >
> > > 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
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Robert Munteanu <ro...@apache.org>.
On Mon, 2020-05-11 at 14:34 -0700, Andreas Schaefer wrote:
> Yes, that sums it up pretty much.
Great!
>
> Also the Kickstart is replacing Launchpad more than the SlingStarter
> as the PMs go to the wayside in favor of the FMs that are then
> managed outside of the Kickstart.
Ack, fully agree on that.
>
> With that said the testing of Sling FM should be done in a new module
> (Kickstart Testing?) than re-using Launchpad Testing but that seems
> to be pretty straight forward as we can use Kickstart Plugin and the
> converted Sling FM.
Not sure about that. The direction we're heading towards is that
Launchpad testing should be going away and the test launcher folded in
the starter. The reasoning is that integration tests in the same module
have a much higher chance of catching regressions early.
But then again I think we should keep this out of scope and focus on
the conversion itself [1].
>
> For me the basics on how to convert Sling to FMs from PMs and how to
> launch it is pretty much laid out. The next part is:
>
> - Create native Sling Module FMs
> - Aggregate them into a Sling FM / FAR
> - Adjust testing
> - Write documentation
> - Composite Nodestore
+1 from me.
Also the composite nodestore is a great feature to have set up. I would
still like to focus on the feature model first, and then on the
niceties :-)
Regarding the feasibility of using the feature model tooling directly,
I was able to tweak your great work from the kickstart and add an 'on-
the-fly' conversion to the Sling Starter, so that the oak_tar aggregate
is packaged. [2]
Proof-of-concept to support the discussion, not necessarily the way we
will go, so it's on a branch for now.
Thanks,
Robert
[1]: https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model#MigratingtheSlingStartertotheFeatureModel-Outofscope
[2]: https://github.com/apache/sling-org-apache-sling-starter/compare/feature/create-feature-aggregate?expand=1
>
> - Andy
>
> > On May 11, 2020, at 2:07 PM, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > 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
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
Yes, that sums it up pretty much.
Also the Kickstart is replacing Launchpad more than the SlingStarter as the PMs go to the wayside in favor of the FMs that are then managed outside of the Kickstart.
With that said the testing of Sling FM should be done in a new module (Kickstart Testing?) than re-using Launchpad Testing but that seems to be pretty straight forward as we can use Kickstart Plugin and the converted Sling FM.
For me the basics on how to convert Sling to FMs from PMs and how to launch it is pretty much laid out. The next part is:
- Create native Sling Module FMs
- Aggregate them into a Sling FM / FAR
- Adjust testing
- Write documentation
- Composite Nodestore
- Andy
> On May 11, 2020, at 2:07 PM, Robert Munteanu <ro...@apache.org> wrote:
>
> 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 <ro...@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
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Robert Munteanu <ro...@apache.org>.
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 <ro...@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
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
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
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.
Cheers - Andy
> On May 11, 2020, at 1:05 PM, Robert Munteanu <ro...@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
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Robert Munteanu <ro...@apache.org>.
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
Re: [discuss] Migrating the Sling Starter to the Feature Model
Posted by Andreas Schaefer <sc...@me.com.INVALID>.
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 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
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. With that building Sling is a mere aggregation of the desired FMs with some minor overarching configurations and repoinit statements.
- Each Sling Modules create its FM
- Kickstart aggregates these Sling Module FMs into Sling FM
or
- Kickstart downloads the Sling FM from a release from a remote Maven repo
- Kickstart launches that Sling FM
The crucial part is that the resulting FM of a Module is added to Maven repository during a release so that users can download them from a remote Maven repo during the Kickstart aggregation without having to build each module on their own.
- Andy
> On May 9, 2020, at 4:32 PM, Robert Munteanu <ro...@apache.org> wrote:
>
> Hi,
>
> I have drafted a wiki page about moving the starter to the feature
> model.
>
> https://cwiki.apache.org/confluence/display/SLING/Migrating+the+Sling+Starter+to+the+Feature+Model
>
> I tried to sum up what I think we want to do, based on multiple mailing
> list threads, and proposed what I think is a workable migration plan.
>
> There are still some open points, and (maybe) some where I was too
> optimistic. Comments are more than welcome, and please correct any
> factual inaccuracies directly in the wiki page.
>
> Thanks,
> Robert
>