ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sibla Wilfried <>
Subject AW: ACE Agent deployment after renaming/changing the agent.identification.agentid property
Date Fri, 07 Feb 2014 13:23:21 GMT
See bellow


> -----Urspr√ľngliche Nachricht-----
> Von: Marcel Offermans []
> Gesendet: Donnerstag, 6. Februar 2014 11:29
> An: ACE-users Apache ACE users
> Betreff: Re: ACE Agent deployment after renaming/changing the
> agent.identification.agentid property
> Hello Wilfried,
> On 05 Feb 2014, at 17:07 pm, Sibla Wilfried <>
> wrote:
> >> So you have many different targets that all have the same initial
> >> installation? Then why not directly give those targets their correct
> >> target ID, have them connect to ACE locally once, and then ship them
> >> with bundle cache and everything? If they end up talking to the same
> >> server, at some point you will have to configure each target anyway.
> > [Wilfried Sibla] The reason is that we are talking about embedded
> devices which are produced by an external manufacturer, including the
> initial installation and also doing some more or less meaningful tests.
> > For this uses case it's not possible to produce a runtime including the
> installed DP in the bundle cache for each target device.
> >
> > Another challenge in this manufacturer scenario is the max time
> available for this action. All initial installation, configuration and all
> tests must be performed within (roundabout) 1:30 minute....
> > I would assume that this isn't possible from a network within the
> factory.
> > Because our device is a small ARM based machine, which needs some time
> for booting the OS, starting the felix etc. And the deployment of a DP
> with roundabout 50 bundles also takes a while on that device.
> Ok, so you need some kind of generic image that is already installed. You
> now use a "default" deployment package that you install into a framework
> once and you are copying that, including the bundle cache, onto these
> devices.
> In that case, I would slightly modify the controller in the agent as
> follows:
> As soon as the controller detects that there is a version of the software
> available for its (new) target ID, it will first uninstall the default
> deployment package. Then it will proceed as normal and install the new
> deployment package.
> This approach does not require any modification to ACE or other "tricks".
> The only downside is that the first software update will contain all the
> bundles (instead of the delta).
[Wilfried Sibla] This could be a solution, but I have some concerns that it solves our requirement.
This would mean that the controller has to uninstall the installed DP before checking the
installed version and also has to request a full DP.
With the consequence, that a full download & installation is required on first contact
with the ACE server. Even if nothing has changed.
I would suppose that this will probably not be accepted by our customers.

> >> It should not be hard to automate the registration of each new target
> >> ID and once you've done that, you can either have a distribution that
> >> is associated to all existing targets, or use some kind of other
> >> scheme te determine what distribution should be linked to the target.
> > [Wilfried Sibla] That's clear how this can be achieved.
> >>
> >> Another problem with your approach is that if you have a "default"
> >> target that has for example version 5 as its latest version, and you
> >> deploy it to a new target, then rename that target and have it poll
> >> again, it will think it still has version 5 of the software
> >> installed, so if you create a new target ID whose version starts at
> >> 1, it will not update the first 5 versions because it thinks it
> >> already has a new version. In short, I would keep target IDs unique
> >> and immutable. There are just too many things in ACE that depend on
> that.
> > [Wilfried Sibla] This issue is also clear. Such a predeployed runtime
> must mandatorily be created with a deployment version 1.0.0. Otherwise
> this will not work.
> For such an initial version, I would even start with a version < 1 because
> ACE always starts at 1, so that way, anything in ACE will replace what was
> there initially.
> > Another option could be to add the functionality to do the initial
> deployment file based directly on the target. But it would also be
> necessary to set the DeploymentPackage-SymbolicName to the target
> identification value.
> If you know the target ID at that point, you could write an InputStream
> wrapper that reads the deployment package and, on the fly, changes that
> name.
> > Another option: building a really small server providing the deployment
> service and assembling the DP from a file structure (quite similar to the
> StreamGenerator) including setting the DeploymentPackage-SymbolicName to
> the value extracted from the HTTP request params (a generic parameter
> replacement in manifest template would also be possible) and the version
> accordingly (probably statically to 1).
> > This solution wouldn't require any changes to ACE, as the other options
> would do.
> To me this sounds like quite a complex solution. I think there are a few
> options above, that don't require changes to ACE either, that are simpler
> to do.

[Wilfried Sibla] Currently I feel that a good option would be to install a initial DP directly
from a directory on the target.
With such a solution a "reset to factory settings" could also be easily realized.
... will keep you informed ...

> Greetings, Marcel

View raw message