Mailing-List: contact users-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@ace.apache.org
Received-SPF: pass (athena.apache.org: domain of marcel.offermans@luminis.eu
 designates 213.199.154.82 as permitted sender)
From: Marcel Offermans <marcel.offermans@luminis.eu>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0E219AEB-3A0F-4ECF-9F13-1BC5A14385BA"
Message-ID: <868E9DC8-0DF6-41DE-946D-5BD884A3B8EB@luminis.eu>
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: ACE Agent deployment after renaming/changing the
 agent.identification.agentid property
Date: Thu, 6 Feb 2014 11:29:28 +0100
References: 
 <CACWOp39zm857r1HpUVS4M=f0h5hsECwiB4ZtS94LuXJ5WjD62Q@mail.gmail.com>
 <CAGrzLmWnoQii80iCDJv=U3KbKSKYfPefDS36myVpzDzPogzBDg@mail.gmail.com>
 <76B27F08-773F-41D2-A970-604D2723545A@luminis.eu>
 <CAKvr0Dou6=M7Sby-72DOgp+_NJvznZHL41K05hKZ7QuzpABmeA@mail.gmail.com>
 <CACWOp39VGxsk3W-H4b6zOj_nNgsVRLPqCHDzhuBE6KZ+VaQvOg@mail.gmail.com>
 <83CCD4C6D2018F4A9E31ABD2C253281C10D51E@imbpw2exd01.bosch-si.com>
 <AB91B1F9-01CD-496A-9AE5-7333E7859E1C@luminis.eu>
 <83CCD4C6D2018F4A9E31ABD2C253281C10D7DA@imbpw2exd01.bosch-si.com>
To: ACE-users Apache ACE users <users@ace.apache.org>
In-Reply-To: <83CCD4C6D2018F4A9E31ABD2C253281C10D7DA@imbpw2exd01.bosch-si.com>

--Apple-Mail=_0E219AEB-3A0F-4ECF-9F13-1BC5A14385BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Hello Wilfried,

On 05 Feb 2014, at 17:07 pm, Sibla Wilfried =
<Wilfried.Sibla@bosch-si.com> 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.
>=20
> 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.
>>=20
>> 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


--Apple-Mail=_0E219AEB-3A0F-4ECF-9F13-1BC5A14385BA--