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 <romb...@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 < > > > > > romb...@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
