You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ace.apache.org by Markus Ruettimann <to...@gmail.com> on 2014/02/02 12:38:28 UTC
BNDtools integration for ACE
Hi
I've read that there should be an integration of ACE into the Eclipse BND
tools. I tried to find that but was not able to. I have found a video:
http://vimeo.com/39229925 that shows what I'm looking for.
My question, ist ACE now integrated int to the BND tools and how can I use
it?
Thanks Markus
AW: AW: ACE user administration persistency
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
Hi Jan
Thx.
Will create a new issue for that.
Greetings
Wilfried
> -----Ursprüngliche Nachricht-----
> Von: Jan Willem Janssen [mailto:janwillem.janssen@luminis.eu]
> Gesendet: Mittwoch, 12. Februar 2014 11:01
> An: users@ace.apache.org
> Betreff: Re: AW: ACE user administration persistency
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Wilfried,
>
> On 11/02/14 20:05, Sibla Wilfried wrote:
> > No, I did a fresh checkout and ran the run-server-allinone. I could
> > add a new user and login successfully with this new user. But after
> > stopping and starting the server again, the user disappeared and could
> > not be used for login.
> >
> > I also switched the "clean storage area before launch" check box in
> > the eclipse bnd launch config.
> >
> > I already tried to find a method where the user is saved, but I
> > didn't find anything.
> >
> > Do I have to configure in the
> > org.apache.ace.configurator.useradmin.task.UpdateUserAdminTask.cfg?
> >
> >
> Or in the org.apache.ace.scheduler.cfg?
> > To sync the users to disc??
>
> I've been able to reproduce the (incorrect) behaviour. It appears that
> indeed the UpdateUserAdminTask is the culprit of this. Could you raise a
> JIRA issue for this?
>
> - --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
> /My world is revolving around PulseOn and Amdatu/
>
> Luminis Technologies B.V.
> J.C. Wilslaan 29
> 7313 HK Apeldoorn
> +31 88 586 46 30
>
> http://www.luminis-technologies.com
> http://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8169.78.566.B.01
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJS+0ZHAAoJEKF/mP2eHDc4V/UQAIU1G04jm/l98Y8PjXUlijtC
> LFzRMnh+90BLhNo4o37j8mBPxQyKLyzK7leIH7qSJc7XfMpvFB3Gl66rdRA1MfB2
> JGul8RHBQm65rbiFK/2R2H0P+c55IGvidTOze9zOSOw+KRtNp7OdGmzuJvolymd6
> PpKZMoerHqhgNd3U3HmOCWfdn1eZrcBmAlt87gJyrYvvkOzhLII9nUeRZ54KAiRz
> uG3VNih6S5Yj3HcmX+mdiCWI1PtQ5tiICQLZOxLEO9nNIOrH+8yhIPID0F1yldMo
> 6JdI8cE0/kg7h14rWAfk2NYMsFEOgC/tcvQ5pu5xX4C15pCuJl/Rw3rB0wbElg+I
> cM6MeY3ZW8pR1o2ndPTxBn+5i6PRrcjqIwv/LfRwEZQI7DQKcH5V5iPoo1HEr7aR
> fYMPGENba/N2VrV1rj3X05Zw/gG3UOAGMCQD2neOJ/cOBs39YN63aw5MA4n6Ewp/
> E54fsTp4FTtwe7qfnwBTK5BCxTF2qCTS7GunHF80vhUPOmjk4teSOwmZJSkDvw6G
> UCleLdwhG5hbrU1Hf/DyPD+H3JIxzjkK+ssz1S8J9IOquTfhcArH0AWzi8L8b+uE
> WZ5oNkcTr5aWglPtt4AHosrnVW6/S6aZQyDllsJzyP+DP7I7S+DgG0NCFDHK4t2J
> Tg4OWXPOnoJ0nF6YoLf/
> =hyLZ
> -----END PGP SIGNATURE-----
Re: AW: ACE user administration persistency
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Wilfried,
On 11/02/14 20:05, Sibla Wilfried wrote:
> No, I did a fresh checkout and ran the run-server-allinone. I could
> add a new user and login successfully with this new user. But after
> stopping and starting the server again, the user disappeared and
> could not be used for login.
>
> I also switched the "clean storage area before launch" check box in
> the eclipse bnd launch config.
>
> I already tried to find a method where the user is saved, but I
> didn't find anything.
>
> Do I have to configure in the
> org.apache.ace.configurator.useradmin.task.UpdateUserAdminTask.cfg?
>
>
Or in the org.apache.ace.scheduler.cfg?
> To sync the users to disc??
I've been able to reproduce the (incorrect) behaviour. It appears that
indeed the UpdateUserAdminTask is the culprit of this. Could you raise
a JIRA issue for this?
- --
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
/My world is revolving around PulseOn and Amdatu/
Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK Apeldoorn
+31 88 586 46 30
http://www.luminis-technologies.com
http://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS+0ZHAAoJEKF/mP2eHDc4V/UQAIU1G04jm/l98Y8PjXUlijtC
LFzRMnh+90BLhNo4o37j8mBPxQyKLyzK7leIH7qSJc7XfMpvFB3Gl66rdRA1MfB2
JGul8RHBQm65rbiFK/2R2H0P+c55IGvidTOze9zOSOw+KRtNp7OdGmzuJvolymd6
PpKZMoerHqhgNd3U3HmOCWfdn1eZrcBmAlt87gJyrYvvkOzhLII9nUeRZ54KAiRz
uG3VNih6S5Yj3HcmX+mdiCWI1PtQ5tiICQLZOxLEO9nNIOrH+8yhIPID0F1yldMo
6JdI8cE0/kg7h14rWAfk2NYMsFEOgC/tcvQ5pu5xX4C15pCuJl/Rw3rB0wbElg+I
cM6MeY3ZW8pR1o2ndPTxBn+5i6PRrcjqIwv/LfRwEZQI7DQKcH5V5iPoo1HEr7aR
fYMPGENba/N2VrV1rj3X05Zw/gG3UOAGMCQD2neOJ/cOBs39YN63aw5MA4n6Ewp/
E54fsTp4FTtwe7qfnwBTK5BCxTF2qCTS7GunHF80vhUPOmjk4teSOwmZJSkDvw6G
UCleLdwhG5hbrU1Hf/DyPD+H3JIxzjkK+ssz1S8J9IOquTfhcArH0AWzi8L8b+uE
WZ5oNkcTr5aWglPtt4AHosrnVW6/S6aZQyDllsJzyP+DP7I7S+DgG0NCFDHK4t2J
Tg4OWXPOnoJ0nF6YoLf/
=hyLZ
-----END PGP SIGNATURE-----
AW: ACE user administration persistency
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
Hi Jan
No, I did a fresh checkout and ran the run-server-allinone.
I could add a new user and login successfully with this new user.
But after stopping and starting the server again, the user disappeared and could not be used for login.
I also switched the "clean storage area before launch" check box in the eclipse bnd launch config.
I already tried to find a method where the user is saved, but I didn't find anything.
Do I have to configure in the org.apache.ace.configurator.useradmin.task.UpdateUserAdminTask.cfg?
Or in the org.apache.ace.scheduler.cfg?
To sync the users to disc??
Greetings
Wilfried
> -----Ursprüngliche Nachricht-----
> Von: Jan Willem Janssen [mailto:janwillem.janssen@luminis.eu]
> Gesendet: Dienstag, 11. Februar 2014 17:26
> An: users@ace.apache.org
> Betreff: Re: ACE user administration persistency
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Wilfried,
>
> On 11/02/14 17:18, Sibla Wilfried wrote:
> > Hi to all
> >
> > A short question to the ACE guys: Using the ACE user administration
> > for adding new user does not store the new user permanently. After
> > restarting the server, I cannot login with the new user any more.
> >
> > I have the impression, that new users are never stored to disk.
> >
> > Does anyone has some experience with this feature? Or did I forget
> > something to configure it accordingly?
> >
> > Some help would be very welcome....
>
> By default, we supply the Felix UserAdmin implementation consisting of two
> bundles: the core UserAdmin functionality and a FileStore backend.
> Did you make any changes to these bundles by any chance?
>
> - --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
> /My world is revolving around PulseOn and Amdatu/
>
> Luminis Technologies B.V.
> J.C. Wilslaan 29
> 7313 HK Apeldoorn
> +31 88 586 46 30
>
> http://www.luminis-technologies.com
> http://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8169.78.566.B.01
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJS+k8FAAoJEKF/mP2eHDc4ODsQAMmgthi/CUTa/pYuendlu4sB
> 3k1nQebwXowycb6BLwOjwh5YRo8P1+IrKs2JSqaNj0j7+lfzLe1sbEp3gtpzQcO2
> S+fDqEX/Ag6t3FoHWQvfnUNZ6gqPhj33fsN2TMUdJXOEzivqwejRol0li0q90Jre
> 3b7hWzRXKfeXDWjsg8X8NMs9LW7yNe/a0vD/AT1rtnNP9Ok74fTwYMBgS36kLP3T
> cD/O25lmwtC/TBSukMME5wt4JGvXFjNYetrYRoZU/hy2iPCqdP1hRqUZt1m6JGC/
> MZ78C+Qr7smU7x0KB1Jh0VbjmsR8dR59bLR4hMbk3vpF0Wzniq1KKMayJMok4oec
> 5ySXJQ5VqIy0zWmI5JPtmsaggfjNGp8UO6LQLyWD+R1EK6ZliieM0k02T8zjfoZP
> 34FvAEO4C8CMNeQpRW8uJsW+LYiCop3iwdncaTScNJ3HOKvafKiSNgjI6tb7c5tf
> kAo2vQoG3eyUqxzHvInJURmkr5R7Sy3/54Gxm4kogo+EBzRCEjDYJ2RL4T67xVI+
> /xnuHa5CQduXxXUsLCfQmkr/aasLq6B73yZNS72AsTTWbV4z+lG5Ee4n7qxa/Wat
> bcW4atQhkHqM4uKAR0g86sNpCOb3ZyBvkyvlMW5WvBjaXNJowiup+42FGUv0MmRS
> 3r3X4siYyJCH7709TlXT
> =PakH
> -----END PGP SIGNATURE-----
Re: ACE user administration persistency
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Wilfried,
On 11/02/14 17:18, Sibla Wilfried wrote:
> Hi to all
>
> A short question to the ACE guys: Using the ACE user administration
> for adding new user does not store the new user permanently. After
> restarting the server, I cannot login with the new user any more.
>
> I have the impression, that new users are never stored to disk.
>
> Does anyone has some experience with this feature? Or did I forget
> something to configure it accordingly?
>
> Some help would be very welcome....
By default, we supply the Felix UserAdmin implementation consisting of
two bundles: the core UserAdmin functionality and a FileStore backend.
Did you make any changes to these bundles by any chance?
- --
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
/My world is revolving around PulseOn and Amdatu/
Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK Apeldoorn
+31 88 586 46 30
http://www.luminis-technologies.com
http://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS+k8FAAoJEKF/mP2eHDc4ODsQAMmgthi/CUTa/pYuendlu4sB
3k1nQebwXowycb6BLwOjwh5YRo8P1+IrKs2JSqaNj0j7+lfzLe1sbEp3gtpzQcO2
S+fDqEX/Ag6t3FoHWQvfnUNZ6gqPhj33fsN2TMUdJXOEzivqwejRol0li0q90Jre
3b7hWzRXKfeXDWjsg8X8NMs9LW7yNe/a0vD/AT1rtnNP9Ok74fTwYMBgS36kLP3T
cD/O25lmwtC/TBSukMME5wt4JGvXFjNYetrYRoZU/hy2iPCqdP1hRqUZt1m6JGC/
MZ78C+Qr7smU7x0KB1Jh0VbjmsR8dR59bLR4hMbk3vpF0Wzniq1KKMayJMok4oec
5ySXJQ5VqIy0zWmI5JPtmsaggfjNGp8UO6LQLyWD+R1EK6ZliieM0k02T8zjfoZP
34FvAEO4C8CMNeQpRW8uJsW+LYiCop3iwdncaTScNJ3HOKvafKiSNgjI6tb7c5tf
kAo2vQoG3eyUqxzHvInJURmkr5R7Sy3/54Gxm4kogo+EBzRCEjDYJ2RL4T67xVI+
/xnuHa5CQduXxXUsLCfQmkr/aasLq6B73yZNS72AsTTWbV4z+lG5Ee4n7qxa/Wat
bcW4atQhkHqM4uKAR0g86sNpCOb3ZyBvkyvlMW5WvBjaXNJowiup+42FGUv0MmRS
3r3X4siYyJCH7709TlXT
=PakH
-----END PGP SIGNATURE-----
Re: ACE user administration persistency
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/02/14 17:18, Sibla Wilfried wrote:
> Some help would be very welcome....
(replying to myself): another thing that could be going on is that the
web user-session failed to initialize properly. This can be checked in
the logs of the (web)server.
- --
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
/My world is revolving around PulseOn and Amdatu/
Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK Apeldoorn
+31 88 586 46 30
http://www.luminis-technologies.com
http://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS+k9MAAoJEKF/mP2eHDc4fHUP/3jzfcJcRoUtHvxQtbvOLogg
oxKjML24oMA6Jjpn1V65EZ4tur7HY1Pjog3N9GO1jmkUV5Ou+9pMnJKoRRenL65q
39SA+kcVxeQqjjdJUwaxkAE3OuE/8RFj+1itHdd74WP3U5LnF4pymHmnttV/iyD8
JztBHYcZn4+YWBM7ldVLfSjMHOvhQk+4HsEnlDBfnUebHvPxUU48meZ2hDzBKhCc
HtTMSTqocYvDPXELPVzlzY1HjfAw8X+bvfVokRWM3nTR8rJ7kR2CxiqPHlaM38Yk
I9wwRDXdT5HFqoGROjKE3R2j/GN5ZBNzDsw0tnLPRblPXdkVYFn9dzMM11dDrA5w
nUBNbfq0kFJXZox854MPwadiXpQYH5FMUdZovXTLfAkH2yJBa0ZQB6tZ+14+JDiY
IjwxrpE3Jq+i14KIvBGinEjPwycc0wycEZeHfXMvd0Cul7/MEzVitb1KUifsOQUc
D4YExqSKrQtDaXd0PsgqMHwDnRs+cDpU7oIoVlHY0HZsaQTGZv/OQ1dUIfCr5TM+
XEOwvfTh/T9Xn3jNoAZwNFMZF+kFtIqsU5tjJzXqnea4YE8R1bKNH8YxlyYxc33T
WuC00Pbi6fzpMkmP4H7mVhZZQZ4UboJ5eGy1G4yNsPl/M4fgBjP5S2bsvnnHNMXA
Ut0aciqpPDW0LMNMWqpI
=hpER
-----END PGP SIGNATURE-----
ACE user administration persistency
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
Hi to all
A short question to the ACE guys:
Using the ACE user administration for adding new user does not store the new user permanently.
After restarting the server, I cannot login with the new user any more.
I have the impression, that new users are never stored to disk.
Does anyone has some experience with this feature? Or did I forget something to configure it accordingly?
Some help would be very welcome....
Thx a lot in advance
AW: ACE Agent deployment after renaming/changing the
agent.identification.agentid property
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
See bellow
Greetings
Wilfried
> -----Ursprüngliche Nachricht-----
> Von: Marcel Offermans [mailto:marcel.offermans@luminis.eu]
> 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 <Wi...@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.
> >
> > 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
Re: ACE Agent deployment after renaming/changing the agent.identification.agentid property
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Wilfried,
On 05 Feb 2014, at 17:07 pm, Sibla Wilfried <Wi...@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.
>
> 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
AW: ACE Agent deployment after renaming/changing the
agent.identification.agentid property
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
Hi Marcel
Thx a lot for your reply. See my comments bellow
Greetings
Wilfried
> -----Ursprüngliche Nachricht-----
> Von: Marcel Offermans [mailto:marcel.offermans@luminis.eu]
> 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 <Wi...@bosch-si.com>
> 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
Re: ACE Agent deployment after renaming/changing the agent.identification.agentid property
Posted by Marcel Offermans <ma...@luminis.eu>.
Hello Wilfried,
On 04 Feb 2014, at 17:13 pm, Sibla Wilfried <Wi...@bosch-si.com> 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.
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.
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.
Greetings, Marcel
ACE Agent deployment after renaming/changing the
agent.identification.agentid property
Posted by Sibla Wilfried <Wi...@bosch-si.com>.
Hello
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.
Regards
Wilfried
Re: BNDtools integration for ACE
Posted by Markus Ruettimann <to...@gmail.com>.
Hi Marcel,
I think, without that Bndtools integration, there is a gap between the
developement and the production runtime environment. It has been proven to
be a good habit to use the same runtime for developement and production.
Sure - ACE is an intermediate step between the application under
developement and the IDE, but such an integration would be a door opener
since only a view runtimes / app containers support IDE integrations but
would suppot an OBR.
Markus
On Sun, Feb 2, 2014 at 8:36 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
> Hi Marcel,
>
> +1 For ACE / Bndtools integration :)
>
> I'm working on a project that has components in different workspaces it
> would be very nice to have these workspaces update bundles in a shared
> environment during development.
>
> Bram
>
>
>
> 2014-02-02 Marcel Offermans <ma...@luminis.eu>
>
> > As Paul says, we're still debating how to proceed with this code.
> >
> > We've integrated ACE into our CI build using scripting. That's working
> > well now, and to get you started, we've done a presentation at the most
> > recent EclipseCon Europe [1].
> >
> > However, the point we're still debating is how to integrate ACE into
> > Bndtools to directly deploy to a local framework (all on one computer).
> We
> > might end up doing that, because we are seeing that there are some
> definite
> > benefits to using exactly the same deployment process throughout the
> whole
> > software development cycle (local development, CI, test, QA, staging,
> > production). We're not there yet though, so this is a good moment to
> > discuss this some more.
> >
> > Greetings, Marcel
> >
> > [1] http://www.youtube.com/watch?v=4S_zvgG_MLw
> >
> >
> > On 02 Feb 2014, at 13:01 pm, Paul Bakker <pa...@luminis.eu> wrote:
> >
> > > Hi Markus,
> > >
> > > The ACE support is a bit outdated and it's removed from the main
> bndtools
> > > release. The code is still there (
> > > https://github.com/bndtools/bndtools/tree/master/bndtools.ace.plugin)
> > > though. I'm not quite sure what to do with this code yet, but there
> seems
> > > to be only limited interest in it, so I'm considering to remove it
> > > entirely. We have come a long way with ACE and automated deployments
> > since
> > > the introduction of the plugin, and scripting ACE is now the preferred
> > way.
> > >
> > > Cheers,
> > >
> > > Paul
> > >
> > >
> > > On Sun, Feb 2, 2014 at 12:38 PM, Markus Ruettimann <toomy711@gmail.com
> > >wrote:
> > >
> > >> Hi
> > >> I've read that there should be an integration of ACE into the Eclipse
> > BND
> > >> tools. I tried to find that but was not able to. I have found a video:
> > >> http://vimeo.com/39229925 that shows what I'm looking for.
> > >>
> > >> My question, ist ACE now integrated int to the BND tools and how can I
> > use
> > >> it?
> > >>
> > >> Thanks Markus
> > >>
> >
> >
>
Re: BNDtools integration for ACE
Posted by Bram Pouwelse <br...@pouwelse.com>.
Hi Marcel,
+1 For ACE / Bndtools integration :)
I'm working on a project that has components in different workspaces it
would be very nice to have these workspaces update bundles in a shared
environment during development.
Bram
2014-02-02 Marcel Offermans <ma...@luminis.eu>
> As Paul says, we're still debating how to proceed with this code.
>
> We've integrated ACE into our CI build using scripting. That's working
> well now, and to get you started, we've done a presentation at the most
> recent EclipseCon Europe [1].
>
> However, the point we're still debating is how to integrate ACE into
> Bndtools to directly deploy to a local framework (all on one computer). We
> might end up doing that, because we are seeing that there are some definite
> benefits to using exactly the same deployment process throughout the whole
> software development cycle (local development, CI, test, QA, staging,
> production). We're not there yet though, so this is a good moment to
> discuss this some more.
>
> Greetings, Marcel
>
> [1] http://www.youtube.com/watch?v=4S_zvgG_MLw
>
>
> On 02 Feb 2014, at 13:01 pm, Paul Bakker <pa...@luminis.eu> wrote:
>
> > Hi Markus,
> >
> > The ACE support is a bit outdated and it's removed from the main bndtools
> > release. The code is still there (
> > https://github.com/bndtools/bndtools/tree/master/bndtools.ace.plugin)
> > though. I'm not quite sure what to do with this code yet, but there seems
> > to be only limited interest in it, so I'm considering to remove it
> > entirely. We have come a long way with ACE and automated deployments
> since
> > the introduction of the plugin, and scripting ACE is now the preferred
> way.
> >
> > Cheers,
> >
> > Paul
> >
> >
> > On Sun, Feb 2, 2014 at 12:38 PM, Markus Ruettimann <toomy711@gmail.com
> >wrote:
> >
> >> Hi
> >> I've read that there should be an integration of ACE into the Eclipse
> BND
> >> tools. I tried to find that but was not able to. I have found a video:
> >> http://vimeo.com/39229925 that shows what I'm looking for.
> >>
> >> My question, ist ACE now integrated int to the BND tools and how can I
> use
> >> it?
> >>
> >> Thanks Markus
> >>
>
>
Re: BNDtools integration for ACE
Posted by Marcel Offermans <ma...@luminis.eu>.
As Paul says, we're still debating how to proceed with this code.
We've integrated ACE into our CI build using scripting. That's working well now, and to get you started, we've done a presentation at the most recent EclipseCon Europe [1].
However, the point we're still debating is how to integrate ACE into Bndtools to directly deploy to a local framework (all on one computer). We might end up doing that, because we are seeing that there are some definite benefits to using exactly the same deployment process throughout the whole software development cycle (local development, CI, test, QA, staging, production). We're not there yet though, so this is a good moment to discuss this some more.
Greetings, Marcel
[1] http://www.youtube.com/watch?v=4S_zvgG_MLw
On 02 Feb 2014, at 13:01 pm, Paul Bakker <pa...@luminis.eu> wrote:
> Hi Markus,
>
> The ACE support is a bit outdated and it's removed from the main bndtools
> release. The code is still there (
> https://github.com/bndtools/bndtools/tree/master/bndtools.ace.plugin)
> though. I'm not quite sure what to do with this code yet, but there seems
> to be only limited interest in it, so I'm considering to remove it
> entirely. We have come a long way with ACE and automated deployments since
> the introduction of the plugin, and scripting ACE is now the preferred way.
>
> Cheers,
>
> Paul
>
>
> On Sun, Feb 2, 2014 at 12:38 PM, Markus Ruettimann <to...@gmail.com>wrote:
>
>> Hi
>> I've read that there should be an integration of ACE into the Eclipse BND
>> tools. I tried to find that but was not able to. I have found a video:
>> http://vimeo.com/39229925 that shows what I'm looking for.
>>
>> My question, ist ACE now integrated int to the BND tools and how can I use
>> it?
>>
>> Thanks Markus
>>
Re: BNDtools integration for ACE
Posted by Paul Bakker <pa...@luminis.eu>.
Hi Markus,
The ACE support is a bit outdated and it's removed from the main bndtools
release. The code is still there (
https://github.com/bndtools/bndtools/tree/master/bndtools.ace.plugin)
though. I'm not quite sure what to do with this code yet, but there seems
to be only limited interest in it, so I'm considering to remove it
entirely. We have come a long way with ACE and automated deployments since
the introduction of the plugin, and scripting ACE is now the preferred way.
Cheers,
Paul
On Sun, Feb 2, 2014 at 12:38 PM, Markus Ruettimann <to...@gmail.com>wrote:
> Hi
> I've read that there should be an integration of ACE into the Eclipse BND
> tools. I tried to find that but was not able to. I have found a video:
> http://vimeo.com/39229925 that shows what I'm looking for.
>
> My question, ist ACE now integrated int to the BND tools and how can I use
> it?
>
> Thanks Markus
>