Hi All, First of all I agree with Daan issue. I have also several improvement/issues myself.
A bit of background. My use case for Apache ACE is a distributed polyglot (Apache Felix / Apache Celix) system where the goal is dynamic (runtime) reconfiguration of the software. One of the project we used Apache ACE in is INAETICS (http://www.inaetics.org/). I worked in this project – among others – together with Jan Willlem. My issues/improvements: - Simpler setup out of the box. The server-allinone contains a lot of feature I personally do not use/need. This makes jumping into Apache ACE difficult. For example - also mentioned by Daan - the need to approve targets is not needed our current use case, but we have to work around this. An other item is the four levels (artifacts, features, distributions targets) as I understand this is adaptable, but out of the box there are four. Maybe different server configuration for different use case can be created. - Support docker Make it possible to "deploy" docker images using Apache ACE. Docker is becoming more popular by the day and in my opinion rightly so. Provisioning docker images in a more controlled manner is IMO still missing. Although using Apache ACE to runtime deploy sets of bundles can be very flexible and powerful in my experience sometimes a pre-created OSGi docker image is preferable. This minimizes the "entropy" of the system by introducing composed OSGi bundles used in a (more) deterministic manner. Although theoretically continuously deploying/undeploying bundles on a OSGi container should work, in practice this can lead to issues (note that should be considered bugs, but still). Also pre-created docker images can be tested as-is and therefore be qualified as whole. A combination would be interesting, so default bundles and the possibility to use Apache ACE to update default bundles / sprinkle on additional bundles. Provide A minimal OSGi client containing the ACE agent and make this images easy extendable by adding additional bundles / configuration files. (See INAETICS (github) for a minimal OSGi client example). Focus on making development of cluster / distributed systems more easy without restarting the cluster. So updated bundles / docker images and restarting ACE client should be possible and easy. – Use the capability-requirement model resolving I would prefer using the capability requirement model to match what to deploy instead of coupling artifact2feature, etc. Although this could maybe be to complex, I think it's worth thinking about. Especially combining this with docker images (e.g. using docker labels to add Provide-Capability / Require-Capability ) could be a interesting feature. This could help in solving a problem where OSGi is very good at, running mircroservices with multiple versions of services. But in this case mircoservices means REST services provided by docker containers. – Runtime configuration When using Apache ACE I often ran in the desire the edit/update the configuration file used. A more “inline” support to updating (e.g. enable debug printing) small configuration files would be nice. - Monitor targets Maybe out of scope for Apache ACE, but also something I noticed would be very welcome when using Apache ACE, is a more elaborate monitoring of the targets. Maybe even something like a heartbeat to ensure the target is alive. - No gosh I understand that gosh is very powerful, but I see it as yet another scripting language I prefer not to learn. I would prefer a more feature rich / responsive HTML UI and better supported REST api. Well these are just my 2 cents. Greetings, Pepijn On Mon, Jan 25, 2016 at 4:04 PM, Daan Veldhof <[email protected]> wrote: > Hi Jan, > > I haven't worked with Ace for that long, but I hope I can add some > feedback, especially from the Celix side. > > - The first challenge i've encountered was that I couldn't upload .zip > files. I know there is a way to create your own resource processor, but it > was easier for me to convert the .zip to .jar. > > - The second challenge was to create targets for celix. We've got celix > working for Android devices, but they need different bundles because most > Android devices contain an ARM processor. The solution for us was to create > multiple targets with their cpu architecture in their id (i.e. > celix_armeabi-v7a or celix_armeabi). I would like to see something were you > could specify the id and in the tags you would specify the cpu > architecture. So if you have a normal linux machine it would register > itself to ace with {id:celix, cpu_arch: linux-x86} and a android device > would register with {id:celix, cpu_arch:armeabi-v7a} > > - The third challenge was to use the REST api. There was some documentation > but it wasn't enough. I looked like someone started with it, but didn't > finish it. Eventually through the mailing-list I got it up and running. > > - The last thing i've encountered was that the automation bundle wasn't > working properly. If a new target was added it wouldn't be registered and > approved. You had to log in and retrieve and store a workspace before it > would be registered and approved. > > Regards, > Daan Veldhof > > > > > > 2016-01-22 15:48 GMT+01:00 Jan Willem Janssen <[email protected]> > : > >> Hi community, >> >> It has been very quiet the past couple of months on the development of >> ACE. I >> am currently busy with picking up the last issues we need to resolve in >> order >> to prepare a new release of ACE (which is long overdue already). >> >> After the release, we’d like to start working on improving ACE again. We >> know >> that ACE has several white spots that might impact its use for your use >> cases. >> Therefore, I’d love to hear your feedback on ACE: issues, abeyance's and >> hurdles you’ve come across and you like to see improved. Other ideas on >> what >> can be improved are welcome as well :) >> >> Thanks in advance, >> >> (cross posting to the dev@ list as well). >> >> -- >> Met vriendelijke groeten | Kind regards >> >> Jan Willem Janssen | Software Architect >> +31 631 765 814 >> >> >> My world is something with Amdatu and Apache >> >> Luminis Technologies >> Churchillplein 1 >> 7314 BZ Apeldoorn >> +31 88 586 46 00 >> >> https://www.luminis.eu >> >> KvK (CoC) 09 16 28 93 >> BTW (VAT) NL8170.94.441.B.01 >> >>
