On Nov 27, 2011, at 11:50 AM, Carsten Ziegeler wrote: > 2011/11/24 Marcel Offermans <marcel.offerm...@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
Cool, writing a small extension to the Sling installer so it fetches a deployment package from an ACE server is fairly trivial. Summarizing what the management agent does, assuming it has the unique ID called "target-id" it will query the server for a list of versions available for itself: http://server:8080/deployment/target-id/versions This will return a list of versions like this: 1.0.0 2.0.0 3.0.0 The default strategy is to always get the latest version: http://server:8080/deployment/target-id/versions/3.0.0 This will return a deployment package which can be installed. That's all there is to it. :) >> 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? No, I'm saying that can be done on the server side. A bit of background. Actually you could also, on the server, directly talk to the "deployment repository" and transmit the artifacts yourself. As it turns out, writing a piece of concurrent code that allows many concurrent clients to poll for such data is not trivial, which is why I added a mechanism to post-process the results of that code. > 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. It can be transformed into something else, as long as it remains one single stream for all artifacts (well, in theory, even that could be changed, but not easily). >> 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. I guess this is a difference between ACE (or rather deployment packages) and the Sling installer. If you have an application installed and there is an update for bundles A, B and C (and we assume there is a bug in B) then ACE will: Start a transaction, install A, install B, discover that that fails and rollback B and A to end up in the original situation again. And from what I understand, Sling will: Install A, install B, discover that that fails, install C, and then keeps retrying B. My concern is that probably, with only A and C installed, the overall application will not work that well, whereas if you roll all changes back, the chances of ending up with an application that works are a lot better. >> 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? Yes. As soon as you allow more than one version of a bundle to be installed at the same time, you end up with problems because you cannot identify in the case of an update, which is an update of which. This, in my opinion, is a "bug" in the OSGi specification, especially now that the 4.3 spec will even allow you to install the same version multiple times. Luckily, in real life, this situation rarely occurs (appearantly). >> 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. Ok. Let's see if anybody at Felix reacts to the plugin Bram donated. If not, it might make sense to add it to Sling's collection, even though ultimately, Felix sounds like the appropriate location for this collection. Greetings, Marcel
