You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2015/06/18 19:35:17 UTC
Possible requirements for crankstart
Now that crankstart is using the provisioning model (thanks Bertrand), I
would like to discuss some potential requirements. We're using a similar
tool as crankstart for a very long time now, and over time we added some
required features. In order to get rid of our own tool, it would be
great if crankstart would provide a similar feature set. It might be
that crankstart is already supporting some of this, this is more or less
a brain dump :)
1. Provide several models on startup - the models are merged into a
single model and then run
2. The above models can be read from a repository
3. Repository support: file url, http url, s3 url
4. Setting the port on startup (overriding a value the model)
5. Setting the context path for the app (overriding a value in the model)
6. Setting the active run modes
7. Setting additional framework properties from the command line
8. Set model variables from the command line - these overwrite values in
the model
9. Provide a way to just download all referenced artifacts and putting
them in a maven repo like file structure
10. Support of the launchpad api startup mode (install, update, restart)
11. Support of the launchpad api startup listener (report startup
finished event when all the stuff from the provisioning model is installed).
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Possible requirements for crankstart
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Sunday 21 June 2015 19:53:09 Carsten Ziegeler wrote:
> Am 21.06.15 um 13:46 schrieb Oliver Lietz:
> > On Friday 19 June 2015 17:37:43 Carsten Ziegeler wrote:
> >> I once started to move this stuff into a separate module but failed to
> >> implement some detail; in retrospect I think I did a mistake while
> >> implementing it. So it should be possible to move this to a bundle.
> >> But maybe with crankstart we can do this more intelligent as I assume
> >> crankstart is in full control of the startup/installation?
> >
> > Can we create a Lauchpad Startup bundle implementing the Lauchpad API
> > which
> > can be used by all launchers (and dropping the naive implementation in
> > org.apache.sling.launchpad.karaf - which is also used in Bertrand's and
> > Artyom's Sling Devops Experiments by Crankstart)?
>
> Yes, I think we can create such a bundle, I already started with that,
> and it should be available in the SVN history.
I do remember that attempt but I couldn't find the JIRA issue for it.
> In general, the goal should be to remove all code from launchpad and
> move it into bundles.
+1
O.
> Carsten
Re: Possible requirements for crankstart
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jun 22, 2015 at 11:00 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...I think right now what we need is a sling-startup-controller
> bundle to implement the controlled incremental startup, and a
> sling-startup-mode bundle for the startup mode detection...
I have created SLING-4851 for that and started to write some tests at
https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/it-startup
to help clarify exactly how these things work.
-Bertrand
Re: Possible requirements for crankstart
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jun 22, 2015 at 2:53 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...In general, the goal should be to remove all code from launchpad and
> move it into bundles...
Agreed - I think right now what we need is a sling-startup-controller
bundle to implement the controlled incremental startup, and a
sling-startup-mode bundle for the startup mode detection.
-Bertrand
Re: Possible requirements for crankstart
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 21.06.15 um 13:46 schrieb Oliver Lietz:
> On Friday 19 June 2015 17:37:43 Carsten Ziegeler wrote:
>
>> I once started to move this stuff into a separate module but failed to
>> implement some detail; in retrospect I think I did a mistake while
>> implementing it. So it should be possible to move this to a bundle.
>> But maybe with crankstart we can do this more intelligent as I assume
>> crankstart is in full control of the startup/installation?
>
> Can we create a Lauchpad Startup bundle implementing the Lauchpad API which
> can be used by all launchers (and dropping the naive implementation in
> org.apache.sling.launchpad.karaf - which is also used in Bertrand's and
> Artyom's Sling Devops Experiments by Crankstart)?
>
Yes, I think we can create such a bundle, I already started with that,
and it should be available in the SVN history.
In general, the goal should be to remove all code from launchpad and
move it into bundles.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Possible requirements for crankstart
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 19 June 2015 17:37:43 Carsten Ziegeler wrote:
> Am 19.06.15 um 17:06 schrieb Bertrand Delacretaz:
[...]
> >> ...10. Support of the launchpad api startup mode (install, update,
> >> restart)...>
> > We might need to refactor some code out of the launchpad to reuse it
> > but that sounds useful. I would add an option to fail in all modes
> > except INSTALL if one wants to enforce immutable Sling instances.
>
> Ok
>
> > A few more comments:
> >
> > Do you think we still need the launchpad's "incremental startup" that
> > raises start levels sequentially with a pause between each? Or was
> > that a workaround for some bugs that are gone today?
>
> I think we still need them - otherwise you end up at the final start
> level but content packages are not installed. With pure Sling and no
> content packages I guess the incremental startup is not needed.
Launchpad Karaf doesn't use startlevels (though supported by Karaf's features)
and Sling works fine here.
> I once started to move this stuff into a separate module but failed to
> implement some detail; in retrospect I think I did a mistake while
> implementing it. So it should be possible to move this to a bundle.
> But maybe with crankstart we can do this more intelligent as I assume
> crankstart is in full control of the startup/installation?
Can we create a Lauchpad Startup bundle implementing the Lauchpad API which
can be used by all launchers (and dropping the naive implementation in
org.apache.sling.launchpad.karaf - which is also used in Bertrand's and
Artyom's Sling Devops Experiments by Crankstart)?
Does Crankstart support the startup modes install/restart/update at all?
[...]
>
> Carsten
Regards,
O.
Re: Possible requirements for crankstart
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 19.06.15 um 17:06 schrieb Bertrand Delacretaz:
>> 3. Repository support: file url, http url, s3 url...
>
> Do s3 URLs need special handling or are they just HTTP?
>
> I suppose some of those might need authentication as well?
>
This needs special handling due to authentication :) The easiest way is
to include the aws libs and use their api to access s3. Doing the http
calls by hand is not really doable.
>> ...9. Provide a way to just download all referenced artifacts and putting
>> them in a maven repo like file structure...
>
> As a way to produce an offline system, is that the use case?
> That's not implemented at this point but I like the idea.
Yes, offline is one use case, but mirroring this to another repository
is the other. So you have all artifacts in a mvn repo and want to
upload/sync them with s3.
>
>> ...10. Support of the launchpad api startup mode (install, update, restart)...
>
> We might need to refactor some code out of the launchpad to reuse it
> but that sounds useful. I would add an option to fail in all modes
> except INSTALL if one wants to enforce immutable Sling instances.
>
Ok
> A few more comments:
>
> Do you think we still need the launchpad's "incremental startup" that
> raises start levels sequentially with a pause between each? Or was
> that a workaround for some bugs that are gone today?
I think we still need them - otherwise you end up at the final start
level but content packages are not installed. With pure Sling and no
content packages I guess the incremental startup is not needed.
I once started to move this stuff into a separate module but failed to
implement some detail; in retrospect I think I did a mistake while
implementing it. So it should be possible to move this to a bundle.
But maybe with crankstart we can do this more intelligent as I assume
crankstart is in full control of the startup/installation?
>
> One thing that we also discussed before but never implemented in
> Crankstart is validating artifacts based on digests specified in the
> provisioning model - I think the model already supports specifying
> such digests?
Yes, the model supports attributes (though I never used/tested them).
You can specify them with [sha=something] directly after the coordinates.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Possible requirements for crankstart
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carsten,
On Thu, Jun 18, 2015 at 7:35 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Now that crankstart is using the provisioning model (thanks Bertrand), I
> would like to discuss some potential requirements....
Thanks for this, I have to look at some of those things in more detail
(which is a good opportunity to document them) before giving a
definite answer, for now will just comment on a few of them.
> 3. Repository support: file url, http url, s3 url...
Do s3 URLs need special handling or are they just HTTP?
I suppose some of those might need authentication as well?
> ...9. Provide a way to just download all referenced artifacts and putting
> them in a maven repo like file structure...
As a way to produce an offline system, is that the use case?
That's not implemented at this point but I like the idea.
> ...10. Support of the launchpad api startup mode (install, update, restart)...
We might need to refactor some code out of the launchpad to reuse it
but that sounds useful. I would add an option to fail in all modes
except INSTALL if one wants to enforce immutable Sling instances.
A few more comments:
Do you think we still need the launchpad's "incremental startup" that
raises start levels sequentially with a pause between each? Or was
that a workaround for some bugs that are gone today?
One thing that we also discussed before but never implemented in
Crankstart is validating artifacts based on digests specified in the
provisioning model - I think the model already supports specifying
such digests?
-Bertrand