ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Hunt <>
Subject Re: [feedback] hurdles when working with ACE
Date Wed, 27 Jan 2016 17:15:13 GMT
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


> On Jan 27, 2016, at 10:57 AM, Jan Willem Janssen <>
> Hi Pepijn,
> Thanks for your elaborate feedback! See my remarks/questions inline.
>> On 25 Jan 2016, at 21:32, Pepijn Noltes <> 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
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8170.94.441.B.01

View raw message