ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <>
Subject Re: Various newbie observations
Date Wed, 05 Oct 2011 08:10:33 GMT
Hi Marcel

On 05.10.2011 09:00:50 Marcel Offermans wrote:
> > I have to say that I don't like the Karaf features as they download many
> > artifacts from possibly different locations. Admins usually want to be
> > in control of what is installed on their systems. Therefore, the fewer
> > artifacts, the better. And I think that Karaf features have a similar
> > problem to the Maven approach of dependency resolution: it's much more
> > difficult to have the overview over all dependencies. Even though it's
> > more work, I like to have full control over which bundles are approved
> > to be used in a system. Downloading the whole internet during deployment
> > only to fail in the last 5% because some artifact is currently
> > unreachable... And if an environment doesn't have access to the internet,
> > you have to make your artifacts locally available anyway.
> What we could do is provide an "import" mechanism that allows us to
> import karaf features into the ACE client, download all dependencies
> and stick them in the ACE OBR, creating a set of artifacts and an associated
> ACE feature for them.

That sounds useful.

> > The ACE GUI is very nice for some first experimentation and demo-ing but
> > IMO becomes more unattractive the further you go towards production
> > deployment.
> Agreed, it needs work if you want to use it for that, adding things
> like proper RBAC, more filtering and sorting options to keep an overview even
> when you have long lists of artifacts, better overview of the history
> and better feedback from targets, etc..
> > But still, I think other ACE components have a high chance
> > of being the right building blocks that I need for my
> > requirements/wishes. I simply have to learn a little more about ACE
> > (especially its client APIs) to find out where they fit in. The client
> > APIs are probably the key to the instant debugging-time deployment.
> Yes, and we have basically two "flavors" of the client side API. One, I
> think you've already looked into by now, consists of a set of OSGi
> services. The other, more recently added, is a REST based client (which
> actually builds on the first).
> Directly hooking up that client to your build process (script or IDE
> based) is indeed the quickest way to instantly deploy things. As a side
> note, if you want to, the client bundles can be run on a different
> machine than the ACE server itself. Right now they are deployed in the
> server because that's the most convenient for a web application but
> before we donated the codebase to Apache we used to have a Swing based
> client that contained those client bundles. That means you're in no way
> required to run the ACE server on your own machine (even though keeping
> everything on your local machine for development might be the easiest
> and quickest way of doing things).

Very good point! Hooking the REST service into the build process should
be more than enough (and much quicker to implement). Uploading a
configuration or another artifact should be easy, too. It's just that
the REST service is a little light on documentation. ;-) I guess I can
try to write that documentation by studying the code.

> > For the production deployment I'm probably looking more at a
> > descriptor-based approach for off-line deployment package assembly
> > (probably Ant-based). The longer I look at ACE, the more I think that
> > some components could really help me but I might not be using it quite
> > along the lines that you guys were initially designing it. But I could
> > be wrong.
> The politically correct answer here probably is that we designed the
> system to be flexible. ;)

Which it really appears to be.

> We did envision different ways in which a deployment package could "end
> up" on a target. The default way is to have the target simply fetch it
> (with an HTTP call) but you can also point the target at a local folder
> and have it install deployment packages from there (creating something
> similar to file install, but with a granularity of a deployment package
> instead of individual bundles and configuration files).
> There is a bit of an ongoing discussion on installing more than one
> deployment package (dp for now) onto a single target. I recently added
> some features for that. However, if you go that way, there are some
> restrictions. First of all, a single bundle can only belong to one dp at
> a time. Second of all, we can no longer validate on the server if what
> you send to a target will work, resolver wise (which we can, and are in
> the process of adding, for a single dp).

Interesting. When I have some experience with the development-time
deployments I guess I'll know if that would improve things.

> > I hope I was able to explain well enough what I'm trying to do.
> I think so. :)
> >>> I'm not using the launcher but a stripped down, minimal
> >>> Apache Karaf because it's easy to deploy that as a service and to
> >>> (low-level) configure. That looks like a promising approach to me so far.
> >> 
> >> The launchers we provide are examples, I'm sure as a community we can come up
with many more!
> > 
> > I guess I can easily write a little essay about the Mini-Karaf approach
> > I'm currently following, when I've gathered some experience with it. I'm
> > also happy to make my Initial Provisioning and the generic mgmt agent
> > available under the ALv2 if anyone thinks that they are useful.
> I think the initial provisioning solution would be a great match for
> the Felix project, because it implements an OSGi specification. For that
> same reason we donated the deployment admin implementation to Felix
> instead of maintaining it in ACE.

Yeah, but so far there was no overwhelming interest in it over @Felix.

> I would love to take a look at the mgmt agent you came up with once you feel it's working
the way you want!

Well, it mostly works already. The only thing really missing is adding
the ability to install configurations to the bootstrap agent. Then I can
activate the property-based discovery service. At the moment I have to
quickly set the configuration via the WebConsole (installed test-wise
with the deployment ZIP) and half a second later, the distribution has
been installed by ACE.

The alternative would be to use a deployment package for the actual
management agent. AutoConf would then help with the discovery
configuration. With the Ant task to create DP's that I was surprised to
discover in ACE, that shouldn's be all that hard. But I'm not sure if it
supports AutoConf. Creating a simple ZIP (with no need for special
ordering and manifests like in DPs) is still easier for experiments.
Maybe I'll add support for both in the bootstrap agent.

Initial Provisioning:
Generic bootstrap agent:
ACE identification service that takes its ID from the
ProvisioningService's SPID:

(sorry, just source JARs at the moment. My build system currently doesn't
make it easy to put a single module in a self-contained package. I will
look into that when the whole thing is more mature so I dare to make a


> I'll keep up the good work. Documentation is definitely still lacking, so keep asking
questions if something's not clear.

Thanks a lot for your help!

> >>> I'll send a patch for the MetaType stuff when I've done a few more of
> >>> those.
> >> 
> >> Great, I saw the patch, thanks a lot! Having the metatype stuff in
> >> place helps a lot, since there are more and more tools nowadays that can use
> >> this information.
> > 
> > Yep. I've been using Felix WebConsole which Metatype turns into a great
> > environment to configure an OSGi application while experimenting with it.
> Exactly! Web console is a great showcase for now metatype works (and many other things
> We've been using the metatype based AutoConfig artifacts a lot to
> provision configuration to a system. In fact, for similar targets we
> even added a way to create a template that gets filled out with
> key/value pairs that can be added to for example individual targets.

Now that is VERY interesting! I know that's going to become an issue for

Jeremias Maerki

View raw message