I have only scanned these emails, and seen some key words such as pluggable storage, REST, modern UI, etc. I’ve been working on just that. If there is any interest, have a look at: https://github.com/BryanHunt/web-in-a-box
Bryan > On Jan 27, 2016, at 10:57 AM, Jan Willem Janssen > <[email protected]> wrote: > > Hi Pepijn, > > Thanks for your elaborate feedback! See my remarks/questions inline. > >> On 25 Jan 2016, at 21:32, Pepijn Noltes <[email protected]> wrote: >> […] >> 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. > > I think we should rethink how ACE by default is going to handle new > targets. With your and Daan’s feedback I do see a real need for that. > >> - 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). > > I see two ways ACE could support Docker: either by provisioning pre-built > Docker images (tarballs) or by provisioning the Dockerfile only and let > the agent on the target build the Docker image for you. Not sure yet > which one is “better”. At the moment, I’m prototyping and playing a bit > with a custom agent that could handle this, just to see how this might > work. > >> 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. > > Do you mean that ACE is acting as a cluster manager, or just provides > the ability to provision multiple targets in a “transactional” manner > (all or nothing approach)? > >> – 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. > > Interesting point. Need to ponder about this a little longer on how > this would work out. > >> – 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. > > Do you mean the configuration of ACE itself, or the configuration > that is provisioned to the targets? > >> - 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. > > The fact that a target periodically sends feedback would actually > provide this information already. But I think you mean that the UI > should actively report when it hasn’t seen/heard from a target in > a while? > >> - 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. > > Fair point: gosh isn’t the most intuitive way of talking to ACE. We > need to come up with another way of doing that from a end-users > perspective (RESTish responsive UI) and from an automation point of > view (for automated deployments, CIs, etc). > > -- > 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 >
