ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: ACE Agent deployment after renaming/changing the agent.identification.agentid property
Date Thu, 06 Feb 2014 10:29:28 GMT
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).

>> 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.

Greetings, Marcel

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