ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: How to rollback a deployment
Date Wed, 29 Oct 2014 07:52:12 GMT
Hello Eduard,

On 24 Oct 2014, at 15:36 pm, Vodicka, Eduard <> wrote:

> I am familiarizing myself with ACE right now and I stumbled across a problem that I don’t
know how to address. I successfully managed to configure my features and distributions and
deployed them to a bunch of targets.


> But what happens, when a Deployment is defective? Maybe one of the bundles does not start
or simply contains a bug that makes it impossible for a user to access his web client. I read
that ACE stores all changes to the deployment configuration like a version control system,
so it should be possible to restore any of the previous versions. But I could not a find a
function that would do that nor any hint in the documentation.

There are two possible scenarios:

1) During the deployment, updating one of the artifacts fails. We are using deployment packages
that conform to the Deployment Admin specification, as defined in the OSGi compendium. This
specification basically states that if something goes wrong during an update, the update will
be rolled back. The management agent by default will retry an update 3 times [1] and then
assume it won't work. At that point it will wait until an even newer version becomes available
and then try again.

2) Deployment does not fail, but functionally something is wrong. This is something ACE cannot
detect on its own because obviously detecting "something is wrong" is specific to your application
domain. This means you need to do some work, namely detect that something went wrong and then
talk to the management agent and tell it what to do. One option for that last bit is to tell
the agent to install an older version of the software. As you might have seen, every time
you change the software configuration for a target, ACE generates a new "version" for that
target. Versions start at 1, and count up. So if the management agent just updated from version
4 to version 5, and after that you detect that version 5 does not work right, you can tell
the agent to install version 4 again.

If you are talking about scenario 2, you will probably end up tweaking the management agent
for this. This is extensively described [2] but does require some work. My proposal would
then be to create a customized management agent, embedding all the logic you need. By keeping
all of that together in a new agent bundle, you can make sure that you can still "update"
the agent itself in cases where you want to improve on the code you wrote and be sure that
that code is always nicely updated together with the rest of the agent. For that reason I
would not recommend writing a separate bundle for the extra logic.

Hope this helps.

Greetings, Marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message