Hello Jamie, everyone, On 16/08/18 10:46, Jamie G. wrote: > Karaf is used / consumed heavily in the SDN world (see OpenDaylight & > its ecosystem). > > For that community they do treat Karaf as a SDK for developing their > apps, its also of course their runtime. > > The long support runs we provide for Karaf major versions is seen as a > benefit as SDN deployments typically run major infrastructure. The > release pace is a function of available time from the community - > speaking from my experiences with Karaf releases they are a fare > amount of work; more hands involved in testing, stabilizing builds, > etc are always welcomed :) > > As to how Karaf is presented; Karaf is many things to many people, I'd > rather keep the open development possibilities than restrict them.
As one of the guys who spent countless hours pushing Karaf upgrades through the OpenDaylight ecosystem and with m OpenDaylight Offset-0 TSC Representative hat on, I would like to contribute the follow to the discussion: I whole-heartily support faster and more predictable release schedule. OpenDaylight follows strict 6 month release cadence (https://opendaylight.readthedocs.io/en/latest/release-process/release-schedule.html). Third-party component upgrades are integrated in the first 6 weeks, with only very minor adjustments being done afterwards. In this context karaf-4.2.1 and karaf-4.1.6 having slipped as much as they did is very bad for ability to plan ahead. Furthermore, so far each and every Karaf upgrade has been problematic -- partly because of the technical debt present in our code base, but more importantly due to sheer amount of changes even a x.x.1 bump in Karaf version brings to the table. Those changes have been quite uncontrolled in the past -- like the change in the default TransformerFactory in 3.0.6, which caused quite a lot of grief evidenced in https://bugs.opendaylight.org/show_bug.cgi?id=5917. While we have reasons for using Karaf in OpenDaylight, it is seen by many developers as an unneeded complication of our platform -- to the point that there is https://lighty.io and https://wiki.opendaylight.org/view/Events:Neon_Dev_Forum#OpenDaylight_without_Karaf_and_OSGi. As far as I understand the motivations, there are three drivers: - regard of OSGi as an unnecessary complication - the kitchen-sink nature of Karaf packaging, which brings unneeded fat, especially considering the general move to stateless containers - slow and painful upgrade process Aside from the schedule, I would like to make two technical asks: 1) Thoroughly document features specification We use features as a deployment descriptor to tie together the components of our system, with the OpenDaylight distribution contains around 300 individual features. While features are cool, they also seem to be quite under-documented, especially in terms of their interplay with the resolver -- for example, what exactly does it exactly mean to declare a feature dependency with dependency=true and prerequisite=true from perspective of feature/bundle lifecycle? 2) Split up feature repositories into individual features OpenDaylight is structured as a set of individual projects, which gradually build up the platform. We use extensively karaf-maven-plugin to generate features and the fact that individual features in features/standard are not available as maven artifacts forces us to define things like https://github.com/opendaylight/odlparent/tree/master/features/odl-karaf-feat-jetty just to get sane features generated without pulling in all of standard. Thanks, Robert
signature.asc
Description: OpenPGP digital signature
