Hi Marcel On 05.10.2011 09:00:50 Marcel Offermans wrote: <snip/> > > 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: http://jeremias-maerki.ch/download/osgi/ch.jm.osgi.provisioning-0.9.0.dev-sources.jar Generic bootstrap agent: http://jeremias-maerki.ch/download/osgi/ch.jm.osgi.management.agent.bootstrap-0.9.0.dev-sources.jar ACE identification service that takes its ID from the ProvisioningService's SPID: http://jeremias-maerki.ch/download/osgi/ch.jm.osgi.management.ace.identification.ip-0.9.0.dev-sources.jar (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 release.) <snip/> > 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 me. Jeremias Maerki
