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 Wed, 05 Feb 2014 16:07:38 GMT
Hi Marcel

Thx a lot for your reply. See my comments bellow


> -----Urspr√ľngliche Nachricht-----
> Von: Marcel Offermans []
> Gesendet: Mittwoch, 5. Februar 2014 15:53
> An: ACE-users Apache ACE users
> Betreff: Re: ACE Agent deployment after renaming/changing the
> agent.identification.agentid property
> Hello Wilfried,
> On 04 Feb 2014, at 17:13 pm, Sibla Wilfried <>
> wrote:
> > I tried to prepare a default target runtime for initial installation.
> > My uses was: creating multiple target environments upfront and initial
> startup with predeployed DP and avoiding immediate deployment after first
> connection to the ACE server (efficient target replication and
> provisioning).
> >
> > I chose the following proceeding:
> >
> > 1.) start my target with ID: default
> > 2.) copied the whole osgi runtime including the bundle cache and its
> configuration to new location
> > 3.) changed the agent.identification.agentid property to e.g.
> myExampleID
> > 4.) start the new target osgi container with ID myExampleID.
> >
> > But this does not work.
> > The reason is that the ACE server is writing the ID of the target into
> the DP manifest as the DeploymentPackage-SymbolicName.
> > And on the other side this value is used by the DeploymentAdmin to
> enable the installation of multiple DPs on a target.
> >
> > Using a fake value as DeploymentPackage-SymbolicName (within the
> StreamGeneratorImpl) and ignoring the identification/target ID in
> DeploymentHandlerImpl.getInstalledVersion() (line 212) could support this
> use case.
> >
> > Could this be a valuable use case for ACE? E.g. in a configurable manner
> (property "use dummy DP-BSN": true/false; as a server and target
> property).
> >
> > Thanks a lot in advance.
> 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.

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

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.

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.

> Greetings, Marcel

View raw message