ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Willem Janssen <>
Subject Re: [feedback] hurdles when working with ACE
Date Wed, 27 Jan 2016 16:57:52 GMT
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

> 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