You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Bruce Edge <br...@nextissuemedia.com> on 2015/01/13 02:16:34 UTC
Sling & dev-ops, crankstart still the preferred option?
I've read Artyom's thesis [1] (nice work BTW if you're reading this) on sling & CI, as well as Bertrand's series of sling dev-ops experiment. I need to start putting together an environment for AWS deployments for sling and I'm wondering if crankstart is still the way forward for automated deployments as opposed to custom launchpad configurations.
Basically wondering if this text from the README is still current: "it might be completely changed, abandoned etc.", or if it's any closer to being an accepted component.
I started looking into AWS's code-deploy [2], which looks a lot like the Orchestrator in [1]. I suppose one has to commit to drink the Amazon kool-aid before considering code-deploy, but given that we're pretty far down that road already, it looks attractive for the Orchestrator component.
Is anyone else working on any AWS-specific deployment work for sling?
-Bruce
[1] http://bdelacretaz.files.wordpress.com/2014/09/artyom-thesis.pdf
[2] http://aws.amazon.com/codedeploy
Re: Sling & dev-ops, crankstart still the preferred option?
Posted by Bruce Edge <br...@nextissuemedia.com>.
>The CrankstartInventoryPrinter spits out a (best effort so far) crankstart
>file from a running Sling instance, just install the
>org.apache.sling.crankstart.api and
>org.apache.sling.crankstart.sling.extensions bundles on that instance and
>go to system/console/status-crankstart . The generated crankstart file
>will
>probably need some tweaks but it's a nice way of cloning a running
>instance
>via crankstart.
Excellent, this is a good place to start. Thanks again for the info
Bertrand.
I will post progress, once I make some...
-Bruce
Re: Sling & dev-ops, crankstart still the preferred option?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tuesday, January 13, 2015, Bruce Edge <br...@nextissuemedia.com>
wrote:
> ...Forgot to ask, are there any docs for crankstart aside from the code
> itself?...
No, but there's not much to document either (*). I think the
launcher/src/test/resources/launcher-test.crank.txt test file demonstrates
all the features.
> ...IMO what would be helpful is an initial crankstart config that
replicates
> the config that one gets with the default sling launchpad...
Like all good software, "it's already in there" is the answer ;-)
>
>
The CrankstartInventoryPrinter spits out a (best effort so far) crankstart
file from a running Sling instance, just install the
org.apache.sling.crankstart.api and
org.apache.sling.crankstart.sling.extensions bundles on that instance and
go to system/console/status-crankstart . The generated crankstart file will
probably need some tweaks but it's a nice way of cloning a running instance
via crankstart.
(*) Ok, so there's something do document now...I've made a note of that.
-Bertrand
Re: Sling & dev-ops, crankstart still the preferred option?
Posted by Bruce Edge <br...@nextissuemedia.com>.
Forgot to ask, are there any docs for crankstart aside from the code
itself?
IMO what would be helpful is an initial crankstart config that replicates
the config that one gets with the default sling launchpad. That would be a
good starting point for noobs like myself.
>I've read Artyom's thesis [1] (nice work BTW if you're reading this) on
>sling & CI, as well as Bertrand's series of sling dev-ops experiment. I
>need to start putting together an environment for AWS deployments for
>sling and I'm wondering if crankstart is still the way forward for
>automated deployments as opposed to custom launchpad configurations.
>Basically wondering if this text from the README is still current: "it
>might be completely changed, abandoned etc.", or if it's any closer to
>being an accepted component.
>
>I started looking into AWS's code-deploy [2], which looks a lot like the
>Orchestrator in [1]. I suppose one has to commit to drink the Amazon
>kool-aid before considering code-deploy, but given that we're pretty far
>down that road already, it looks attractive for the Orchestrator
>component.
>
>Is anyone else working on any AWS-specific deployment work for sling?
>
>-Bruce
>
>[1] http://bdelacretaz.files.wordpress.com/2014/09/artyom-thesis.pdf
>[2] http://aws.amazon.com/codedeploy
>
>
>
>
Re: Sling & dev-ops, crankstart still the preferred option?
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 13.01.15 um 07:53 schrieb Bertrand Delacretaz:
>
> The logical next step would be to adapt crankstart to use the provisioning
> model that was created in the meantime
> (tooling/support/provisioning-model), we designed it to be compatible with
> the crankstart idea but that hasn't been implemented yet.
>
Yepp, I also think we should switch our launchpad to use the
provisioning model, so regardless of which approach you use, the
definition is the same.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Sling & dev-ops, crankstart still the preferred option?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Bruce,
On Tuesday, January 13, 2015, Bruce Edge <br...@nextissuemedia.com>
wrote:
> ...I'm wondering if crankstart is still the way forward for automated
deployments
> as opposed to custom launchpad configurations....
I haven't heard from anybody besides Artyom and myself using it so far, so
while I still think it's a great solution for immutable instances it's not
an "official" part of Sling at the moment. OTOH it's not much code so even
if you had to maintain it yourself that wouldn't be the end of the world -
in the end Sling is just a set of OSGi bundles with configs. And
contributions are welcome in this area of course.
The logical next step would be to adapt crankstart to use the provisioning
model that was created in the meantime
(tooling/support/provisioning-model), we designed it to be compatible with
the crankstart idea but that hasn't been implemented yet.
> ...I started looking into AWS's code-deploy [2], which looks a lot like
the Orchestrator in [1].
> I suppose one has to commit to drink the Amazon kool-aid before
> considering code-deploy...
Yeah, if you agree to get married with a vendor there's lots of nice tools
out there.
I'm not sure how far Sling needs to go, I suppose best is for us to be
friendly to those different tools so that Sling users can select what's
best for them. What's very welcome in this case is blog posts or other
reports of how you get those things up and running.
-Bertrand