See bellow Greetings Wilfried
> -----Ursprüngliche Nachricht----- > Von: Marcel Offermans [mailto:[email protected]] > 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 <[email protected]> > 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
