ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Using the Sling OSGi Installer?
Date Sun, 27 Nov 2011 10:50:35 GMT
2011/11/24 Marcel Offermans <marcel.offermans@luminis.nl>:
> Let me start by explaining this in a bit more detail (while I'm trying to understand
exactly how the Sling installer works):
>
> At a high level, ACE consists of a server and a management agent running within the target
OSGi container. The management agent first asks the server about available versions of the
software, and if there's something new, the next request it sends is to actually get this
new version.
>
> The response from the server now by default is a Deployment Package that either contains
the delta of artifacts between two versions, or a full set of artifacts. Within that deployment
package, artifacts have a type, and for all non-bundle types, a resource processor is also
shipped as part of the package.
>
> On the server side we have a mechanism now that allows us to literally "post process"
that deployment package and transform it into something else. Like Karl says, we've used that
to create PojoSR JAR files (just as a proof of concept for now) but that shows we can do all
kinds of transformations on them.
>
> I can see a couple of ways to integrate the Sling installer into ACE:
>
> 1) You state that the Sling installer already supports Deployment Packages. That actually
means that it could just fetch one from the ACE server and install it. That sounds like the
easiest solution and would probably require only very little modifications to the installer.
Yes

>
> 2) Create a post processor that transforms a deployment package into something else that
is more suitable for the Sling installer, and have that installer "fetch" that something and
install it. We now fetch everything in one go, so I'm not sure how that would map.
>
> 3) Create a post procesor that transforms a deployment package into a fully self-contained
installer that contains both the installer itself and the actual set of artifacts (this would
be similar to our PojoSR experiment). It does not necessarily cater for updates this way,
but it would be a very convenient way to bootstrap using a single, executable jar file.

I'm not sure if I can follow you for the last two points :)  I haven't
looked at latest ACE yet, but my understanding was that it's possible
to deploy other artifacts than deployment packages (at least in theory
maybe). So are you saying, these are always transferred as deployment
packages and then transformed into the "correct" artifact on the
client installing this stuff? This would be possible with the Sling
installer as well as we have the concept of transformers. If something
else is than a deployment package is transferred this can be directly
installed by a plugin.


>
> Conceptually, this is very close to what the ACE management agent does, with perhaps
the difference that we use Deployment Admin as the basis and that that spec defines a single
package that contains both the artifacts and the handlers. On the target side, we send artifacts
to handlers as well to physically install them, and this is done in the context of a session
or transaction that also supports rollback.
>
> Having the Sling installer as an "alternative" management agent sounds like something
we should look at supporting.
>
> We could even look at if we can bridge the Sling handlers to/from Resource Processors
to/from File Install plugins. However, I know that at least File Install does not know how
to deal with sessions/transactions and rollback changes if something went wrong. How is that
for the Sling handlers?
We don't have a rollback mechanism but a retry - so the basic idea is
- if something is about to be installed, it really should be tried as
hard as possible. So if an install fails, the installer retries it,
after something else has been installed. So for example, if a bundle
is missing during the first try, and this one gets installed later,
the installer retries and everything is fine.
On the other hand, the Sling installer is able to do a rollback if the
artifact disappears from the provider.

>
> Interesting. Does that mean that manual changes are always preserved, and override automatic
updates?
Yes.

> Does this also mean that, like with deployment packages, you can only install one single
version of a bundle A at a time?
Yes.

> In the context of ACE and Karaf features, we ran into an issue that for example, if you
have an installation that includes bundles:
>
>  * A 1.0
>  * A 1.1
>
> and you then create a new version that contains:
>
> * A 2.0
> * A 2.1
>
> that you cannot detemine which is an update of which. OSGi simply does not provide enough
metadata for that. For now we have no solution for that yet (Karaf simply does not support
updates at all, but to me that is not acceptable since that means loosing your bundle data
area).

These are packages containing the same bundle in different versions?

>
> Are those plugins for File Install part of Sling? I am wondering where we should collect
them (in the context of Bram's mail about his contribution to Felix).

Right now we have everything in the Sling SVN. Like Bertrand said, I
see no problem in giving others commit for Sling to work on this. We
could also move the installer to Felix or somewhere else.

Regards
Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message