ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Various newbie observations
Date Wed, 05 Oct 2011 07:00:50 GMT
Hello Jeremias,

On Oct 3, 2011, at 9:27 AM, Jeremias Maerki wrote:

> Hi Marcel
> 
> On 30.09.2011 21:02:54 Marcel Offermans wrote:
>> Hello Jeremias,
>> 
>> On Sep 30, 2011, at 10:29 AM, Jeremias Maerki wrote:
>> 
>>> I'm looking into adopting parts of Apache ACE as the deployment tool for
>>> an appliciation I'm writing. It's my second attempt with ACE now, after
>>> my first that wasn't so successful. I'm starting to find my way around
>>> the project by studying lots of source code and starting to add MetaType
>>> information to make it easier to play with configuration settings.
>> 
>> Cool, thanks!
>> 
>>> Some background on what I'm trying to do if you're interested: I've
>>> written a partial implementation of the OSGi Initial Provisioning server
>>> [1]. Then I wrote a generic bootstrap agent that starts the actual
>>> management agent (most probably a customized ACE if I can get it to do
>>> what I need).
>> 
>> Feel free to explain exactly what you need.
> 
> So far, I've been working with FileInstall to deploy modified bundles
> on-the-fly during development. That gives me very quick turn-arounds
> when debugging. Now, I'm at a point where I need to transform my
> single-instance system into a fully clustered one. During the
> development I'd like to keep the ability for a high
> debugging-productivity so I'd like to have a changed bundle distributed
> to all instances in the cluster immediately after it's built. My
> Ant-based build system currently copies every bundle directly into a
> FileInstall-observed directory.

Sound familiar. That's what I did a lot of the time as well. Nowadays, I tend to use BndTools
a lot which builds and deploys my bundles on the fly as well, but only to one single, local
target. The need to have a quick cycle here is something I think we all agree on.

> OTOH, approaching the point where my system needs to be packaged into an
> actual product, I need a versionable way of deploying the application.
> The application should be packaged into as few files as possible (think
> deployment packages, which I find a great concept). The configuration
> should be versionable, too, but probably deployed seperately to the
> actual bundles because they have different deployment schedules. I think
> the Features/Distribution grouping of ACE should accomodate this just
> fine.

Agreed, deployment packages are a very nice way of installing and updating, not only because
they allow you to package everything in one file but also because of the transactional properties
and their extendability through resource processors.

> 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.

> 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).

> 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.
;)

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).

> 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.

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!

>>> So while digging around the project I noticed a few things:
>>> - first of all, a nicely divided and designed set of bundles that
>>> promises high flexibility and extensibility. Nice!
>> 
>> Thanks!
>> 
>>> - the source code is an ugly mix of spaces and tabs for indentation.
>>> Please talk among yourselves towards one or the other (I prefer spaces).
>>> A very minimal Checkstyle configuration file might be helpful, too.
>> 
>> We have a style guide, but we lack a checkstyle and/or Eclipse formatters right now.
Check out this page and let me know what you think:
>> http://incubator.apache.org/ace/java-coding-style-guide.html
> 
> Took me a while to find the link to that page on the website. I'm not
> sure that placing/hiding that under "Building Apache ACE" is the best
> idea. Anyway, I'm happy to see that the ground rules are already
> established. Time to enforce them. :-)

:)

>> I'll try to at least come up with a formatter for Eclipse (which is my weapon of
choice).
> 
> Mine, too. :-) Formatter settings, Checkstyle rules. Reduced to the
> minimum to enforce some ground rules but to still allow for some
> flexibility. We've made the mistake in Apache FOP to have too many rules
> which leaves much too many warnings to ever be cleaned up. Well, that
> project is 12 years old so is bound to have some "diversity" piled up.
> :-)
> 
> If you want I'll look into a Checkstyle file based on your style guide.

That would be great!

>>> - A lot of svn:ignores are missing (see attached patch)
>> 
>> Thanks!
>> 
>>> - as long as the documentation is a little spotty (which is ok at this
>>> stage), please think about filling out the <description> tag in the POMs
>>> for each bundle so it's easier to get at least an idea what some bundle
>>> does. A little README would even be better. I think that would spare a
>>> lot of would-be adopters a lot of time finding their way around the
>>> project. I've had to regularly wander around the source code to figure
>>> out what a bundle is supposed to do.
>> 
>> Excellent idea. I'll spend some time to do that. I can see how that helps.
> 
> Great! Thanks! The ones you put in so far are already VERY helpful! The
> client APIs are probably where I head next.

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

>>> 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.

Greetings, Marcel


Mime
View raw message