You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Toni Menzel <to...@rebaze.com> on 2018/08/16 08:09:55 UTC
Karaf target audience and release granularity
As mentioned, here are some more thoughts on Karaf audience/usage.
Do you know how Karaf users consume/use Karaf? This is important to get a
good release cycle and granularity. (as teased by JB on this list recently).
Why i am mentioning that? Well,i always felt that Karaf (the container) is
a rather large thing with all its feature repos coming with it. I think
thats why Karaf releases where coming rather slow in the past. (correct or
not?)
*1. Karaf as an opinionated felix distro*
This "batteries" included feature is (was?) a core selling point of Karaf
but is this really how people use it?
I know at least two larger customers who are baking their own Karaf
distribution anyway based on the minimal profile.
So i am asking, wouldn't it make sense to release the "base" runtime (say
Felix+Karaf infrastructure like pax-url, feature system, configuration
system) independently? Similar to what you get with Karaf minimal.
Depending on how Karaf is used in the real world (do you know?), here are
some radical thoughts on my/our personal usage:
- Karaf Minimal becomes "Karaf Runtime" because its base unit you can
put everything on top (even at runtime).
- Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
kitchen-sink nature that is great when you want to tinker with
Spring,Hibernate etc.
Also, wouldn't it make sense to release the maven-plugin independently?
Those changes might seem of no importance to Karaf insiders (because you
get all of that already when building your own distro) but at least I only
found Karaf reasonable for a lot of usecases until i found out how to
really only get the "runtime" part. Now i can say that for me Karaf is an
opinionated felix distro (yes.. not only that but you get the point).
*2. Karaf as polymorphic container*
On the website Karaf is marketed as "Karaf can host any kind of
applications: OSGi, Spring, WAR, and much more". Is that how people really
use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
Every OSGi-savvy person recommends going DS, staying with OSGi spec
standards and avoid War. - pun intended.
Yeah, its great for demos but is it worth the effort? - also to keep this
"working". And - from experience - i can tell that its also not a
recommendable migration path. It sounds great but Hibernate and friends are
actually quite hostile to your OSGi framework instance introducing a lot
more complexity into your system. And if even OSGi-savvy people have
problems troubleshooting such cases, how should a team of beginners do that?
*3. Karaf as a better solution for Microservices*
Guess i save this for another post, too easy to turn this into a rant. Let
me just say: i think Karaf is one of the few answers to the pervasive
Microservice/Spring Boot ecosystem. But it is not obvious and people stay
away from it because. Again, this COULD go very long, but it is not the
right place.
Any thoughts?
* What is Developer Ergonomics <https://medium.com/rebaze>**? *
*www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
<http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I guess for async.
Regards
JB
On 19/08/2018 12:21, Francois Papon wrote:
> Hi,
>
> I don't really understand why using JMS, can you explain ?
>
> regards,
>
> François Papon
> fpapon@apache.org
>
> Le 19/08/2018 à 03:13, Castor a écrit :
>> "by the way, what do you mean about remote admin ? Is it something like
>> the Deployer feature we have in Cave?"
>>
>> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
>> also created a suport to pre and post install hooks and plugins, blue-green
>> deployment, remote health checks and so on.
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Francois Papon <fr...@openobject.fr>.
Ok, thanks !
It's great to ear usages of Karaf ;)
As JB said, the last release of Karaf Cave provider the Deployer helping
to deal with Karaf instance administration and it also provide an API Rest.
You can take a look to the implementation, may be you can find some
usefull stuff :
https://github.com/apache/karaf-cave/blob/master/deployer/rest/src/main/java/org/apache/karaf/cave/deployer/rest/DeployerRest.java
regards,
François Papon
fpapon@apache.org
Le 19/08/2018 à 18:40, Castor a écrit :
> Sure! Here our software works mostly on premises and we need a two-way
> communication, a JMX connection from our admin to thousands of clients would
> be a pain, also there are some commands we need a guarantee of execution and
> JMS help us with that.
>
>
> fpapon wrote
>> Hi,
>>
>> I don't really understand why using JMS, can you explain ?
>>
>> regards,
>>
>> François Papon
>> fpapon@
>> Le 19/08/2018 à 03:13, Castor a écrit :
>>> "by the way, what do you mean about remote admin ? Is it something like
>>> the Deployer feature we have in Cave?"
>>>
>>> Yes! the deploy module is quite similar, but using JMS instead of JMX,
>>> i've
>>> also created a suport to pre and post install hooks and plugins,
>>> blue-green
>>> deployment, remote health checks and so on.
>>>
>>>
>>>
>>> --
>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Karaf target audience and release granularity
Posted by Castor <yg...@gmail.com>.
Sure! Here our software works mostly on premises and we need a two-way
communication, a JMX connection from our admin to thousands of clients would
be a pain, also there are some commands we need a guarantee of execution and
JMS help us with that.
fpapon wrote
> Hi,
>
> I don't really understand why using JMS, can you explain ?
>
> regards,
>
> François Papon
> fpapon@
>
> Le 19/08/2018 à 03:13, Castor a écrit :
>> "by the way, what do you mean about remote admin ? Is it something like
>> the Deployer feature we have in Cave?"
>>
>> Yes! the deploy module is quite similar, but using JMS instead of JMX,
>> i've
>> also created a suport to pre and post install hooks and plugins,
>> blue-green
>> deployment, remote health checks and so on.
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Karaf target audience and release granularity
Posted by Francois Papon <fr...@openobject.fr>.
Hi,
I don't really understand why using JMS, can you explain ?
regards,
François Papon
fpapon@apache.org
Le 19/08/2018 à 03:13, Castor a écrit :
> "by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave?"
>
> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
> also created a suport to pre and post install hooks and plugins, blue-green
> deployment, remote health checks and so on.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Catcha.
Don't hesitate to create a Jira to extend the Cave Deployer to use the
same features !
Regards
JB
On 19/08/2018 01:13, Castor wrote:
> "by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave?"
>
> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
> also created a suport to pre and post install hooks and plugins, blue-green
> deployment, remote health checks and so on.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
That sounds like Cave Deployer to me.
Regards
JB
On 19/08/2018 08:27, Christian Schneider wrote:
> Sounds interesting. Do you think you could write blog about your approach?
>
> Christian
>
> Am So., 19. Aug. 2018 um 01:42 Uhr schrieb Castor <yg...@gmail.com>:
>
>> "by the way, what do you mean about remote admin ? Is it something like
>> the Deployer feature we have in Cave?"
>>
>> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
>> also created a suport to pre and post install hooks and plugins, blue-green
>> deployment, remote health checks and so on.
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Christian Schneider <ch...@die-schneider.net>.
Sounds interesting. Do you think you could write blog about your approach?
Christian
Am So., 19. Aug. 2018 um 01:42 Uhr schrieb Castor <yg...@gmail.com>:
> "by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave?"
>
> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
> also created a suport to pre and post install hooks and plugins, blue-green
> deployment, remote health checks and so on.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
Re: Karaf target audience and release granularity
Posted by Castor <yg...@gmail.com>.
"by the way, what do you mean about remote admin ? Is it something like
the Deployer feature we have in Cave?"
Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
also created a suport to pre and post install hooks and plugins, blue-green
deployment, remote health checks and so on.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I disagree here. We can have different perspective.
We have some users that use Karaf on Docker for infra, and use Cellar
with Kubernetes for node discovery. That's an approach.
Another option is to use the Karaf static profile (we have an example
now in the distribution) or a custom distribution (thanks for the
assembly/docker scripts we now have in the distribution).
As reminder, this is a Karaf related mailing list.
Regards
JB
On 18/08/2018 19:24, Christian Schneider wrote:
> For cloud deployments you normally want to implement the immutable server
> pattern:
> https://martinfowler.com/bliki/ImmutableServer.html
>
> This means that your whole deployment including config should be defined
> from e.g. a github repository.
> You do not want to have upgrades of bundles or config during the lifetime
> of a pod. Of course your still want to have this for development.
> So you need some assembly process but it completely happens at build time
> of the docker image.
> You then want to feed some instance specific config using env variables.
>
> So translated to karaf the ideal deployment is to resolve the features at
> build time and only deploy a list of bundles.
> This can already be done using the static profile of karaf.
> Overriding the config using env variables is possible using the new felix
> configurator. It is not yet added to karaf but should be no bigger issue.
> So basically you create a custom distro with static profile, your features
> and the configurator. Then you create a docker image from it.
> The result should then behave quite nicely in kubernetes.
>
> I would not use the karaf clustering features (cellar). As you deploy
> static docker images the cellar features do not help much.
> So in summary karaf can be nicely tailored for kubernetes. I think though
> that you can go even smaller without karaf if you want to go for kubernetes.
>
> I am currently epxerimenting with the new OSGi R7 features that allow to do
> an assembly based on annotations. So for example the new http whiteboard
> annotations
> have a dual purpose. They tell the http service to install a service as a
> servlet but they also add a requirement for a whiteboard extender.
> These annotations allow to do a deployment without specifiying features. If
> you use them well you can simply tell the resolver to deploy your bundle,
> give it a repository of
> bundles and it automatically selects a good set of bundles.
> I am currently doing this with a bndrun file using the bnd maven plugins.
> The result of the build is then a runnable jar that looks like what spring
> boot produces.
> It is quite easy to create a docker image from this and run it in
> kubernetes.
> See this example https://github.com/cschneider/osgi-example-systemready.
>
> I am pretty sure we can use the new R7 annotations to also make karaf
> deployments simpler.
>
> I will do a talk about systemready and kubernetes at adaptto 2018.
> For javaland 2019 I proposed a talk about Cloud native OSGi. The idea is to
> check how well OSGi already fits into the cloud and what we need to make it
> fully cloud native.
>
> Christian
>
> .Am Sa., 18. Aug. 2018 um 18:08 Uhr schrieb Matt Sicker <bo...@gmail.com>:
>
>>
>> I'm not sure how much you've used Kubernetes, but I wonder how well Karaf
>> Boot could work in that sphere. I still believe strongly in modularity and
>> the ecosystem around it, and if Karaf makes it easier to "migrate to the
>> cloud" so to say (and not just in a superficial matter; modularity should
>> help enforce boundaries that are explicitly needed in distributed systems),
>> then that could be a killer feature. The existing work with clustering
>> looks extremely relevant to this, though I'm not familiar with how that
>> interacts with k8s.
>>
>> On Fri, 17 Aug 2018 at 23:09, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> Hi,
>>>
>>> by the way, what do you mean about remote admin ? Is it something like
>>> the Deployer feature we have in Cave ?
>>>
>>> By the way, I will take some days off next week, but after I will send a
>>> proposal on the mailing list with:
>>>
>>> 1. Release agenda
>>> 2. Karaf Container roadmap
>>> 3. Karaf Vineyard
>>>
>>> Stay tuned !
>>>
>>> Regards
>>> JB
>>>
>>> On 17/08/2018 22:12, Castor wrote:
>>>> Ohh yeah, at the beginning the mechanism was quite confusing, it still
>>> give
>>>> me some headaches sometimes, like a feature with no dependencies with a
>>>> bundle importing only a servlet triggering a refresh of the whole
>>> platform.
>>>>
>>>> "For the update, I don't know which karaf version you are using, but
>>>> Karaf 4.2.x has some improvements with feature:update."
>>>>
>>>> We are using karaf 4.1.5 right now, we will wait for Karaf 4.2.1 to
>> start
>>>> some testing.
>>>>
>>>>
>>>> "Feel free to create Jira corresponding
>>>> to your ideas, and feel free to contribute. Any help is welcome !"
>>>>
>>>> Will do, i plan to release an open-source version of our remote admin
>> for
>>>> karaf which i am working on my free time, should take a couple months.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>>
>>>> jbonofre wrote
>>>>> Hi,
>>>>>
>>>>> Thanks for sharing your experience.
>>>>>
>>>>> I don't say that it's your case, but most of the time, when people
>>>>> complains about refresh, it's because they don't know/understand the
>>>>> underlying mechanisms.
>>>>> Basically, I had the case with a customer that used a bunch of
>> optional
>>>>> import and complain of the refresh: the issue was basically a design
>>>>> error and an mistake in the bundles.
>>>>>
>>>>> For the update, I don't know which karaf version you are using, but
>>>>> Karaf 4.2.x has some improvements with feature:update.
>>>>>
>>>>> About spring-boot like, it's part of the karaf-boot scope.
>>>>>
>>>>> Anyway guys, I think you have very good ideas and it's really great
>> you
>>>>> share your experience/use cases. Feel free to create Jira
>> corresponding
>>>>> to your ideas, and feel free to contribute. Any help is welcome !
>>>>>
>>>>> Thanks
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 17/08/2018 21:34, Castor wrote:
>>>>>> I can tell a little about my experience with karaf.
>>>>>>
>>>>>> Here we have an ERP writen in delphi (that was written in natural
>>> before
>>>>>> that) which we need to "upgrade" to a cloud capable software, using
>> the
>>>>>> same
>>>>>> database and mantaining the old software while we rewrite negotial
>>> rules
>>>>>> in
>>>>>> java. Great part of our clients are small-medium with on-premises, so
>>> we
>>>>>> had
>>>>>> to maintain a architecture easy enough for on-premises and able to
>> use
>>> a
>>>>>> cloud structure with clusters and so on.
>>>>>>
>>>>>> So, we are using karaf for that, OSGi services lets us to build
>>>>>> "microservices" and have a easier reuse of Negotial Rules, with
>> common
>>>>>> transactions and so on (icks for XA .
>>>>>>
>>>>>> Well, it works, but we have some headaches, we had to build or own
>>>>>> dependency mechanism, because every single feature refreshed the hell
>>> of
>>>>>> karaf, we also built an remote admin to update services on-the-fly in
>>>>>> every
>>>>>> single customer, it's working quite nicely, we still have some
>> trouble
>>>>>> with
>>>>>> failed bundles, but nothing irremediable.
>>>>>>
>>>>>> Two things that would help us a lot, a spring-boot like app and an
>>> easier
>>>>>> way to update karaf version, for the updates we had to create a
>> updater
>>>>>> which saves a list of negotial bundles, reinstall karaf and restores
>>> the
>>>>>> bundles, it works but it's quite meh.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>>>>>
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>
>>>>> jbonofre@
>>>>
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Christian Schneider <ch...@die-schneider.net>.
For cloud deployments you normally want to implement the immutable server
pattern:
https://martinfowler.com/bliki/ImmutableServer.html
This means that your whole deployment including config should be defined
from e.g. a github repository.
You do not want to have upgrades of bundles or config during the lifetime
of a pod. Of course your still want to have this for development.
So you need some assembly process but it completely happens at build time
of the docker image.
You then want to feed some instance specific config using env variables.
So translated to karaf the ideal deployment is to resolve the features at
build time and only deploy a list of bundles.
This can already be done using the static profile of karaf.
Overriding the config using env variables is possible using the new felix
configurator. It is not yet added to karaf but should be no bigger issue.
So basically you create a custom distro with static profile, your features
and the configurator. Then you create a docker image from it.
The result should then behave quite nicely in kubernetes.
I would not use the karaf clustering features (cellar). As you deploy
static docker images the cellar features do not help much.
So in summary karaf can be nicely tailored for kubernetes. I think though
that you can go even smaller without karaf if you want to go for kubernetes.
I am currently epxerimenting with the new OSGi R7 features that allow to do
an assembly based on annotations. So for example the new http whiteboard
annotations
have a dual purpose. They tell the http service to install a service as a
servlet but they also add a requirement for a whiteboard extender.
These annotations allow to do a deployment without specifiying features. If
you use them well you can simply tell the resolver to deploy your bundle,
give it a repository of
bundles and it automatically selects a good set of bundles.
I am currently doing this with a bndrun file using the bnd maven plugins.
The result of the build is then a runnable jar that looks like what spring
boot produces.
It is quite easy to create a docker image from this and run it in
kubernetes.
See this example https://github.com/cschneider/osgi-example-systemready.
I am pretty sure we can use the new R7 annotations to also make karaf
deployments simpler.
I will do a talk about systemready and kubernetes at adaptto 2018.
For javaland 2019 I proposed a talk about Cloud native OSGi. The idea is to
check how well OSGi already fits into the cloud and what we need to make it
fully cloud native.
Christian
.Am Sa., 18. Aug. 2018 um 18:08 Uhr schrieb Matt Sicker <bo...@gmail.com>:
>
> I'm not sure how much you've used Kubernetes, but I wonder how well Karaf
> Boot could work in that sphere. I still believe strongly in modularity and
> the ecosystem around it, and if Karaf makes it easier to "migrate to the
> cloud" so to say (and not just in a superficial matter; modularity should
> help enforce boundaries that are explicitly needed in distributed systems),
> then that could be a killer feature. The existing work with clustering
> looks extremely relevant to this, though I'm not familiar with how that
> interacts with k8s.
>
> On Fri, 17 Aug 2018 at 23:09, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi,
> >
> > by the way, what do you mean about remote admin ? Is it something like
> > the Deployer feature we have in Cave ?
> >
> > By the way, I will take some days off next week, but after I will send a
> > proposal on the mailing list with:
> >
> > 1. Release agenda
> > 2. Karaf Container roadmap
> > 3. Karaf Vineyard
> >
> > Stay tuned !
> >
> > Regards
> > JB
> >
> > On 17/08/2018 22:12, Castor wrote:
> > > Ohh yeah, at the beginning the mechanism was quite confusing, it still
> > give
> > > me some headaches sometimes, like a feature with no dependencies with a
> > > bundle importing only a servlet triggering a refresh of the whole
> > platform.
> > >
> > > "For the update, I don't know which karaf version you are using, but
> > > Karaf 4.2.x has some improvements with feature:update."
> > >
> > > We are using karaf 4.1.5 right now, we will wait for Karaf 4.2.1 to
> start
> > > some testing.
> > >
> > >
> > > "Feel free to create Jira corresponding
> > > to your ideas, and feel free to contribute. Any help is welcome !"
> > >
> > > Will do, i plan to release an open-source version of our remote admin
> for
> > > karaf which i am working on my free time, should take a couple months.
> > >
> > > Thanks!
> > >
> > >
> > >
> > >
> > > jbonofre wrote
> > >> Hi,
> > >>
> > >> Thanks for sharing your experience.
> > >>
> > >> I don't say that it's your case, but most of the time, when people
> > >> complains about refresh, it's because they don't know/understand the
> > >> underlying mechanisms.
> > >> Basically, I had the case with a customer that used a bunch of
> optional
> > >> import and complain of the refresh: the issue was basically a design
> > >> error and an mistake in the bundles.
> > >>
> > >> For the update, I don't know which karaf version you are using, but
> > >> Karaf 4.2.x has some improvements with feature:update.
> > >>
> > >> About spring-boot like, it's part of the karaf-boot scope.
> > >>
> > >> Anyway guys, I think you have very good ideas and it's really great
> you
> > >> share your experience/use cases. Feel free to create Jira
> corresponding
> > >> to your ideas, and feel free to contribute. Any help is welcome !
> > >>
> > >> Thanks
> > >> Regards
> > >> JB
> > >>
> > >> On 17/08/2018 21:34, Castor wrote:
> > >>> I can tell a little about my experience with karaf.
> > >>>
> > >>> Here we have an ERP writen in delphi (that was written in natural
> > before
> > >>> that) which we need to "upgrade" to a cloud capable software, using
> the
> > >>> same
> > >>> database and mantaining the old software while we rewrite negotial
> > rules
> > >>> in
> > >>> java. Great part of our clients are small-medium with on-premises, so
> > we
> > >>> had
> > >>> to maintain a architecture easy enough for on-premises and able to
> use
> > a
> > >>> cloud structure with clusters and so on.
> > >>>
> > >>> So, we are using karaf for that, OSGi services lets us to build
> > >>> "microservices" and have a easier reuse of Negotial Rules, with
> common
> > >>> transactions and so on (icks for XA .
> > >>>
> > >>> Well, it works, but we have some headaches, we had to build or own
> > >>> dependency mechanism, because every single feature refreshed the hell
> > of
> > >>> karaf, we also built an remote admin to update services on-the-fly in
> > >>> every
> > >>> single customer, it's working quite nicely, we still have some
> trouble
> > >>> with
> > >>> failed bundles, but nothing irremediable.
> > >>>
> > >>> Two things that would help us a lot, a spring-boot like app and an
> > easier
> > >>> way to update karaf version, for the updates we had to create a
> updater
> > >>> which saves a list of negotial bundles, reinstall karaf and restores
> > the
> > >>> bundles, it works but it's quite meh.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> > >>>
> > >>
> > >> --
> > >> Jean-Baptiste Onofré
> > >
> > >> jbonofre@
> > >
> > >> http://blog.nanthrax.net
> > >> Talend - http://www.talend.com
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
Re: Karaf target audience and release granularity
Posted by Matt Sicker <bo...@gmail.com>.
I haven't directly used Karaf in a couple years, so I can't speak to what
my old team did with my old app, but we had a hell of a time upgrading
between point releases of Karaf. Part of that was immaturity at the time in
automating our infrastructure, but another part was simply trying to
coordinate the underlying framework version across dozens of bundles got to
be a hot mess. It reminded me of upgrading major Java versions somewhat but
with more surprises. We also maintained a manual features list that we had
to keep up to date with our Maven and then later Gradle build; that was
irritating, but not as bad as it was when we first started writing the
application and were keeping versions in sync across even more places. The
speed of development (particularly in the ability to redeploy a single
bundle at a time), however, absolutely made up for the arcane process at
the time. I was hoping to eventually split up that application into smaller
.kar files to allow for easier deployments of the subsystems, but I never
had a chance to do that before I left, though I'm not even sure how well
that would've helped compared to just dropping jars in the deploy directory
for a more granular deployment.
I'm not sure how much you've used Kubernetes, but I wonder how well Karaf
Boot could work in that sphere. I still believe strongly in modularity and
the ecosystem around it, and if Karaf makes it easier to "migrate to the
cloud" so to say (and not just in a superficial matter; modularity should
help enforce boundaries that are explicitly needed in distributed systems),
then that could be a killer feature. The existing work with clustering
looks extremely relevant to this, though I'm not familiar with how that
interacts with k8s.
On Fri, 17 Aug 2018 at 23:09, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave ?
>
> By the way, I will take some days off next week, but after I will send a
> proposal on the mailing list with:
>
> 1. Release agenda
> 2. Karaf Container roadmap
> 3. Karaf Vineyard
>
> Stay tuned !
>
> Regards
> JB
>
> On 17/08/2018 22:12, Castor wrote:
> > Ohh yeah, at the beginning the mechanism was quite confusing, it still
> give
> > me some headaches sometimes, like a feature with no dependencies with a
> > bundle importing only a servlet triggering a refresh of the whole
> platform.
> >
> > "For the update, I don't know which karaf version you are using, but
> > Karaf 4.2.x has some improvements with feature:update."
> >
> > We are using karaf 4.1.5 right now, we will wait for Karaf 4.2.1 to start
> > some testing.
> >
> >
> > "Feel free to create Jira corresponding
> > to your ideas, and feel free to contribute. Any help is welcome !"
> >
> > Will do, i plan to release an open-source version of our remote admin for
> > karaf which i am working on my free time, should take a couple months.
> >
> > Thanks!
> >
> >
> >
> >
> > jbonofre wrote
> >> Hi,
> >>
> >> Thanks for sharing your experience.
> >>
> >> I don't say that it's your case, but most of the time, when people
> >> complains about refresh, it's because they don't know/understand the
> >> underlying mechanisms.
> >> Basically, I had the case with a customer that used a bunch of optional
> >> import and complain of the refresh: the issue was basically a design
> >> error and an mistake in the bundles.
> >>
> >> For the update, I don't know which karaf version you are using, but
> >> Karaf 4.2.x has some improvements with feature:update.
> >>
> >> About spring-boot like, it's part of the karaf-boot scope.
> >>
> >> Anyway guys, I think you have very good ideas and it's really great you
> >> share your experience/use cases. Feel free to create Jira corresponding
> >> to your ideas, and feel free to contribute. Any help is welcome !
> >>
> >> Thanks
> >> Regards
> >> JB
> >>
> >> On 17/08/2018 21:34, Castor wrote:
> >>> I can tell a little about my experience with karaf.
> >>>
> >>> Here we have an ERP writen in delphi (that was written in natural
> before
> >>> that) which we need to "upgrade" to a cloud capable software, using the
> >>> same
> >>> database and mantaining the old software while we rewrite negotial
> rules
> >>> in
> >>> java. Great part of our clients are small-medium with on-premises, so
> we
> >>> had
> >>> to maintain a architecture easy enough for on-premises and able to use
> a
> >>> cloud structure with clusters and so on.
> >>>
> >>> So, we are using karaf for that, OSGi services lets us to build
> >>> "microservices" and have a easier reuse of Negotial Rules, with common
> >>> transactions and so on (icks for XA .
> >>>
> >>> Well, it works, but we have some headaches, we had to build or own
> >>> dependency mechanism, because every single feature refreshed the hell
> of
> >>> karaf, we also built an remote admin to update services on-the-fly in
> >>> every
> >>> single customer, it's working quite nicely, we still have some trouble
> >>> with
> >>> failed bundles, but nothing irremediable.
> >>>
> >>> Two things that would help us a lot, a spring-boot like app and an
> easier
> >>> way to update karaf version, for the updates we had to create a updater
> >>> which saves a list of negotial bundles, reinstall karaf and restores
> the
> >>> bundles, it works but it's quite meh.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >
> >> jbonofre@
> >
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >
> >
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Matt Sicker <bo...@gmail.com>
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
by the way, what do you mean about remote admin ? Is it something like
the Deployer feature we have in Cave ?
By the way, I will take some days off next week, but after I will send a
proposal on the mailing list with:
1. Release agenda
2. Karaf Container roadmap
3. Karaf Vineyard
Stay tuned !
Regards
JB
On 17/08/2018 22:12, Castor wrote:
> Ohh yeah, at the beginning the mechanism was quite confusing, it still give
> me some headaches sometimes, like a feature with no dependencies with a
> bundle importing only a servlet triggering a refresh of the whole platform.
>
> "For the update, I don't know which karaf version you are using, but
> Karaf 4.2.x has some improvements with feature:update."
>
> We are using karaf 4.1.5 right now, we will wait for Karaf 4.2.1 to start
> some testing.
>
>
> "Feel free to create Jira corresponding
> to your ideas, and feel free to contribute. Any help is welcome !"
>
> Will do, i plan to release an open-source version of our remote admin for
> karaf which i am working on my free time, should take a couple months.
>
> Thanks!
>
>
>
>
> jbonofre wrote
>> Hi,
>>
>> Thanks for sharing your experience.
>>
>> I don't say that it's your case, but most of the time, when people
>> complains about refresh, it's because they don't know/understand the
>> underlying mechanisms.
>> Basically, I had the case with a customer that used a bunch of optional
>> import and complain of the refresh: the issue was basically a design
>> error and an mistake in the bundles.
>>
>> For the update, I don't know which karaf version you are using, but
>> Karaf 4.2.x has some improvements with feature:update.
>>
>> About spring-boot like, it's part of the karaf-boot scope.
>>
>> Anyway guys, I think you have very good ideas and it's really great you
>> share your experience/use cases. Feel free to create Jira corresponding
>> to your ideas, and feel free to contribute. Any help is welcome !
>>
>> Thanks
>> Regards
>> JB
>>
>> On 17/08/2018 21:34, Castor wrote:
>>> I can tell a little about my experience with karaf.
>>>
>>> Here we have an ERP writen in delphi (that was written in natural before
>>> that) which we need to "upgrade" to a cloud capable software, using the
>>> same
>>> database and mantaining the old software while we rewrite negotial rules
>>> in
>>> java. Great part of our clients are small-medium with on-premises, so we
>>> had
>>> to maintain a architecture easy enough for on-premises and able to use a
>>> cloud structure with clusters and so on.
>>>
>>> So, we are using karaf for that, OSGi services lets us to build
>>> "microservices" and have a easier reuse of Negotial Rules, with common
>>> transactions and so on (icks for XA .
>>>
>>> Well, it works, but we have some headaches, we had to build or own
>>> dependency mechanism, because every single feature refreshed the hell of
>>> karaf, we also built an remote admin to update services on-the-fly in
>>> every
>>> single customer, it's working quite nicely, we still have some trouble
>>> with
>>> failed bundles, but nothing irremediable.
>>>
>>> Two things that would help us a lot, a spring-boot like app and an easier
>>> way to update karaf version, for the updates we had to create a updater
>>> which saves a list of negotial bundles, reinstall karaf and restores the
>>> bundles, it works but it's quite meh.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>>
>>
>> --
>> Jean-Baptiste Onofré
>
>> jbonofre@
>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Castor <yg...@gmail.com>.
Ohh yeah, at the beginning the mechanism was quite confusing, it still give
me some headaches sometimes, like a feature with no dependencies with a
bundle importing only a servlet triggering a refresh of the whole platform.
"For the update, I don't know which karaf version you are using, but
Karaf 4.2.x has some improvements with feature:update."
We are using karaf 4.1.5 right now, we will wait for Karaf 4.2.1 to start
some testing.
"Feel free to create Jira corresponding
to your ideas, and feel free to contribute. Any help is welcome !"
Will do, i plan to release an open-source version of our remote admin for
karaf which i am working on my free time, should take a couple months.
Thanks!
jbonofre wrote
> Hi,
>
> Thanks for sharing your experience.
>
> I don't say that it's your case, but most of the time, when people
> complains about refresh, it's because they don't know/understand the
> underlying mechanisms.
> Basically, I had the case with a customer that used a bunch of optional
> import and complain of the refresh: the issue was basically a design
> error and an mistake in the bundles.
>
> For the update, I don't know which karaf version you are using, but
> Karaf 4.2.x has some improvements with feature:update.
>
> About spring-boot like, it's part of the karaf-boot scope.
>
> Anyway guys, I think you have very good ideas and it's really great you
> share your experience/use cases. Feel free to create Jira corresponding
> to your ideas, and feel free to contribute. Any help is welcome !
>
> Thanks
> Regards
> JB
>
> On 17/08/2018 21:34, Castor wrote:
>> I can tell a little about my experience with karaf.
>>
>> Here we have an ERP writen in delphi (that was written in natural before
>> that) which we need to "upgrade" to a cloud capable software, using the
>> same
>> database and mantaining the old software while we rewrite negotial rules
>> in
>> java. Great part of our clients are small-medium with on-premises, so we
>> had
>> to maintain a architecture easy enough for on-premises and able to use a
>> cloud structure with clusters and so on.
>>
>> So, we are using karaf for that, OSGi services lets us to build
>> "microservices" and have a easier reuse of Negotial Rules, with common
>> transactions and so on (icks for XA .
>>
>> Well, it works, but we have some headaches, we had to build or own
>> dependency mechanism, because every single feature refreshed the hell of
>> karaf, we also built an remote admin to update services on-the-fly in
>> every
>> single customer, it's working quite nicely, we still have some trouble
>> with
>> failed bundles, but nothing irremediable.
>>
>> Two things that would help us a lot, a spring-boot like app and an easier
>> way to update karaf version, for the updates we had to create a updater
>> which saves a list of negotial bundles, reinstall karaf and restores the
>> bundles, it works but it's quite meh.
>>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
Thanks for sharing your experience.
I don't say that it's your case, but most of the time, when people
complains about refresh, it's because they don't know/understand the
underlying mechanisms.
Basically, I had the case with a customer that used a bunch of optional
import and complain of the refresh: the issue was basically a design
error and an mistake in the bundles.
For the update, I don't know which karaf version you are using, but
Karaf 4.2.x has some improvements with feature:update.
About spring-boot like, it's part of the karaf-boot scope.
Anyway guys, I think you have very good ideas and it's really great you
share your experience/use cases. Feel free to create Jira corresponding
to your ideas, and feel free to contribute. Any help is welcome !
Thanks
Regards
JB
On 17/08/2018 21:34, Castor wrote:
> I can tell a little about my experience with karaf.
>
> Here we have an ERP writen in delphi (that was written in natural before
> that) which we need to "upgrade" to a cloud capable software, using the same
> database and mantaining the old software while we rewrite negotial rules in
> java. Great part of our clients are small-medium with on-premises, so we had
> to maintain a architecture easy enough for on-premises and able to use a
> cloud structure with clusters and so on.
>
> So, we are using karaf for that, OSGi services lets us to build
> "microservices" and have a easier reuse of Negotial Rules, with common
> transactions and so on (icks for XA .
>
> Well, it works, but we have some headaches, we had to build or own
> dependency mechanism, because every single feature refreshed the hell of
> karaf, we also built an remote admin to update services on-the-fly in every
> single customer, it's working quite nicely, we still have some trouble with
> failed bundles, but nothing irremediable.
>
> Two things that would help us a lot, a spring-boot like app and an easier
> way to update karaf version, for the updates we had to create a updater
> which saves a list of negotial bundles, reinstall karaf and restores the
> bundles, it works but it's quite meh.
>
>
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Castor <yg...@gmail.com>.
I can tell a little about my experience with karaf.
Here we have an ERP writen in delphi (that was written in natural before
that) which we need to "upgrade" to a cloud capable software, using the same
database and mantaining the old software while we rewrite negotial rules in
java. Great part of our clients are small-medium with on-premises, so we had
to maintain a architecture easy enough for on-premises and able to use a
cloud structure with clusters and so on.
So, we are using karaf for that, OSGi services lets us to build
"microservices" and have a easier reuse of Negotial Rules, with common
transactions and so on (icks for XA .
Well, it works, but we have some headaches, we had to build or own
dependency mechanism, because every single feature refreshed the hell of
karaf, we also built an remote admin to update services on-the-fly in every
single customer, it's working quite nicely, we still have some trouble with
failed bundles, but nothing irremediable.
Two things that would help us a lot, a spring-boot like app and an easier
way to update karaf version, for the updates we had to create a updater
which saves a list of negotial bundles, reinstall karaf and restores the
bundles, it works but it's quite meh.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
Re: Karaf target audience and release granularity
Posted by Francois Papon <fr...@openobject.fr>.
yes, +1 for the description :)
François Papon
fpapon@apache.org
On 16/08/2018 12:50, Jamie G. wrote:
> I like the phrase "Product Project", perhaps we should add that to
> Karaf's description ;)
> On Thu, Aug 16, 2018 at 6:18 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Toni,
>>
>> I know a fairly large set of users that use Karaf without knowing OSGi.
>>
>> That's why it's a polymorphic container: some use spring, some use OSGi,
>> some use blueprint, some use directly war, etc. There are several facet
>> of using Karaf.
>>
>> About the distribution, to be honest, I only know users of standard
>> distribution: either directly Karaf vanilla and then installing features
>> and their applications, or creating their own custom distribution
>> starting from the standard one. They don't necessary use the enterprise
>> features, it's more the standard distribution + their own features.
>>
>> One of the key part of Karaf is use friendly. That's the difference
>> starting from the framework. When you start from felix framework, it's
>> up to you to construct all: logging management, hot deployment, ...
>> Starting from Karaf it's a turnkey solution, having all user facing aspects.
>> Karaf container and all its subprojects are really focused on user.
>>
>> Look at Decanter: it's tremendous simple solution but it does the job
>> and users just use it.
>>
>> Karaf is a "product project", it's not a SDK. It's a multi-purpose
>> runtime, powered by OSGi, but OSGi is not necessary the user facing model.
>>
>> That's why, as a "product project", I think it makes sense to have
>> regular release pace.
>>
>> Regards
>> JB
>>
>> On 16/08/2018 10:09, Toni Menzel wrote:
>>> As mentioned, here are some more thoughts on Karaf audience/usage.
>>>
>>> Do you know how Karaf users consume/use Karaf? This is important to get a
>>> good release cycle and granularity. (as teased by JB on this list recently).
>>>
>>> Why i am mentioning that? Well,i always felt that Karaf (the container) is
>>> a rather large thing with all its feature repos coming with it. I think
>>> thats why Karaf releases where coming rather slow in the past. (correct or
>>> not?)
>>>
>>> *1. Karaf as an opinionated felix distro*
>>>
>>> This "batteries" included feature is (was?) a core selling point of Karaf
>>> but is this really how people use it?
>>> I know at least two larger customers who are baking their own Karaf
>>> distribution anyway based on the minimal profile.
>>>
>>> So i am asking, wouldn't it make sense to release the "base" runtime (say
>>> Felix+Karaf infrastructure like pax-url, feature system, configuration
>>> system) independently? Similar to what you get with Karaf minimal.
>>>
>>> Depending on how Karaf is used in the real world (do you know?), here are
>>> some radical thoughts on my/our personal usage:
>>>
>>> - Karaf Minimal becomes "Karaf Runtime" because its base unit you can
>>> put everything on top (even at runtime).
>>> - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
>>> kitchen-sink nature that is great when you want to tinker with
>>> Spring,Hibernate etc.
>>>
>>> Also, wouldn't it make sense to release the maven-plugin independently?
>>>
>>> Those changes might seem of no importance to Karaf insiders (because you
>>> get all of that already when building your own distro) but at least I only
>>> found Karaf reasonable for a lot of usecases until i found out how to
>>> really only get the "runtime" part. Now i can say that for me Karaf is an
>>> opinionated felix distro (yes.. not only that but you get the point).
>>>
>>> *2. Karaf as polymorphic container*
>>>
>>> On the website Karaf is marketed as "Karaf can host any kind of
>>> applications: OSGi, Spring, WAR, and much more". Is that how people really
>>> use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
>>> Every OSGi-savvy person recommends going DS, staying with OSGi spec
>>> standards and avoid War. - pun intended.
>>> Yeah, its great for demos but is it worth the effort? - also to keep this
>>> "working". And - from experience - i can tell that its also not a
>>> recommendable migration path. It sounds great but Hibernate and friends are
>>> actually quite hostile to your OSGi framework instance introducing a lot
>>> more complexity into your system. And if even OSGi-savvy people have
>>> problems troubleshooting such cases, how should a team of beginners do that?
>>>
>>> *3. Karaf as a better solution for Microservices*
>>>
>>> Guess i save this for another post, too easy to turn this into a rant. Let
>>> me just say: i think Karaf is one of the few answers to the pervasive
>>> Microservice/Spring Boot ecosystem. But it is not obvious and people stay
>>> away from it because. Again, this COULD go very long, but it is not the
>>> right place.
>>>
>>> Any thoughts?
>>>
>>> * What is Developer Ergonomics <https://medium.com/rebaze>**? *
>>>
>>>
>>>
>>> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
>>> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by "Jamie G." <ja...@gmail.com>.
I like the phrase "Product Project", perhaps we should add that to
Karaf's description ;)
On Thu, Aug 16, 2018 at 6:18 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Toni,
>
> I know a fairly large set of users that use Karaf without knowing OSGi.
>
> That's why it's a polymorphic container: some use spring, some use OSGi,
> some use blueprint, some use directly war, etc. There are several facet
> of using Karaf.
>
> About the distribution, to be honest, I only know users of standard
> distribution: either directly Karaf vanilla and then installing features
> and their applications, or creating their own custom distribution
> starting from the standard one. They don't necessary use the enterprise
> features, it's more the standard distribution + their own features.
>
> One of the key part of Karaf is use friendly. That's the difference
> starting from the framework. When you start from felix framework, it's
> up to you to construct all: logging management, hot deployment, ...
> Starting from Karaf it's a turnkey solution, having all user facing aspects.
> Karaf container and all its subprojects are really focused on user.
>
> Look at Decanter: it's tremendous simple solution but it does the job
> and users just use it.
>
> Karaf is a "product project", it's not a SDK. It's a multi-purpose
> runtime, powered by OSGi, but OSGi is not necessary the user facing model.
>
> That's why, as a "product project", I think it makes sense to have
> regular release pace.
>
> Regards
> JB
>
> On 16/08/2018 10:09, Toni Menzel wrote:
> > As mentioned, here are some more thoughts on Karaf audience/usage.
> >
> > Do you know how Karaf users consume/use Karaf? This is important to get a
> > good release cycle and granularity. (as teased by JB on this list recently).
> >
> > Why i am mentioning that? Well,i always felt that Karaf (the container) is
> > a rather large thing with all its feature repos coming with it. I think
> > thats why Karaf releases where coming rather slow in the past. (correct or
> > not?)
> >
> > *1. Karaf as an opinionated felix distro*
> >
> > This "batteries" included feature is (was?) a core selling point of Karaf
> > but is this really how people use it?
> > I know at least two larger customers who are baking their own Karaf
> > distribution anyway based on the minimal profile.
> >
> > So i am asking, wouldn't it make sense to release the "base" runtime (say
> > Felix+Karaf infrastructure like pax-url, feature system, configuration
> > system) independently? Similar to what you get with Karaf minimal.
> >
> > Depending on how Karaf is used in the real world (do you know?), here are
> > some radical thoughts on my/our personal usage:
> >
> > - Karaf Minimal becomes "Karaf Runtime" because its base unit you can
> > put everything on top (even at runtime).
> > - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
> > kitchen-sink nature that is great when you want to tinker with
> > Spring,Hibernate etc.
> >
> > Also, wouldn't it make sense to release the maven-plugin independently?
> >
> > Those changes might seem of no importance to Karaf insiders (because you
> > get all of that already when building your own distro) but at least I only
> > found Karaf reasonable for a lot of usecases until i found out how to
> > really only get the "runtime" part. Now i can say that for me Karaf is an
> > opinionated felix distro (yes.. not only that but you get the point).
> >
> > *2. Karaf as polymorphic container*
> >
> > On the website Karaf is marketed as "Karaf can host any kind of
> > applications: OSGi, Spring, WAR, and much more". Is that how people really
> > use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
> > Every OSGi-savvy person recommends going DS, staying with OSGi spec
> > standards and avoid War. - pun intended.
> > Yeah, its great for demos but is it worth the effort? - also to keep this
> > "working". And - from experience - i can tell that its also not a
> > recommendable migration path. It sounds great but Hibernate and friends are
> > actually quite hostile to your OSGi framework instance introducing a lot
> > more complexity into your system. And if even OSGi-savvy people have
> > problems troubleshooting such cases, how should a team of beginners do that?
> >
> > *3. Karaf as a better solution for Microservices*
> >
> > Guess i save this for another post, too easy to turn this into a rant. Let
> > me just say: i think Karaf is one of the few answers to the pervasive
> > Microservice/Spring Boot ecosystem. But it is not obvious and people stay
> > away from it because. Again, this COULD go very long, but it is not the
> > right place.
> >
> > Any thoughts?
> >
> > * What is Developer Ergonomics <https://medium.com/rebaze>**? *
> >
> >
> >
> > *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> > <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Toni,
That's an aspect of Karaf that we should improve, and that's exactly the
purpose of:
1. The examples coming in the 4.2.1 (as part of the standard
distribution): https://github.com/jbonofre/karaf/tree/DEV_GUIDE
2. karaf-boot.
I started karaf-boot exactly to facilitate the view of Karaf for developers.
Even if the focus is users first, we should extend to have a "Karaf
developer friendly", even simplifying some OSGi parts for non OSGi
people. It means that Karaf Boot will do choices: it will engage
developers on some well defined patterns. Of course, there will be lot
of different alternatives, but karaf-boot will follow one.
The karaf-boot tagline is "just do your business code, karaf-boot deals
with the rest". So basically, you will add some karaf-boot annotations
in your code, and karaf-boot will create the artifacts, even the Karaf
distribution, for you.
However, I still think that our highest priority audience is
users/devops, and the second audience is devs.
François and I are working on Karaf Vineyard (API Registry/Gateway),
focused really on service platform for users/devops.
I would love to have some feedback and helps on karaf-boot (the repo is
on my github).
Thanks Toni !
Regards
JB
On 16/08/2018 12:14, Toni Menzel wrote:
> Thanks everyone for your quick replies.
>
> I see your point, JB. "One of the key part of Karaf is use friendly." thats
> what i mean by "opinionated felix distro".
> It may sound as a bad thing but i mean it as a feature: it puts "batteries"
> included onto the osgi fw, has opinions how to configure stuff and where
> logs go and how to do things you normally would expect from a complete
> solution.
> I would expect use-friendliness should be a feature of every product. Who
> wants software that is hostile at you ? ;)
>
> About "Product Project" well ok then. Thats the "Product Karaf" direction.
> Good one!
>
> Though, there might be room for improvements in the area "Karaf for SDK
> Vendors"?
> Treat the following as insight into how we use Karaf "not" as a product but
> as the fabric for (business-) developers.
> Our customers are building developer experiences (e.g. APIs for specific
> problem domains) on top of Karaf Minimal.
>
> 1. We take Karaf Minimal and create custom distributions with all
> technical features embedded, preconfigured & tested.This often includes a
> lot of messy "OSGi-fied" legacy projects too.
> 2. We add business-centric/domain APIs to that distro. This is the
> user-facing programming model. The only thing that leaks technically is the
> fact that usually the model is being accessed as OSGi Services using DS.
> But this is even exchangeable.We call the user-facing api "baseline api".
> 3. They get all this as an "SDK" which is made of a Docker Image,
> Zip-Assembly and as an on-demand/per-user cloud service (all runtimes) and
> Baseline-APIs artifacts (compile target).
> 4. They program against the baseline-api producing deliverables (usually
> OSGi Bundles but could be anything accepted by the runtime).
> 5. Delivery is very customer specific, ranging from pre-baking "all
> included" docker images or an app-store-like SaaS Model.
>
> So we treat Karaf (and with it OSGi) as the internal fabric that is
> technically exposed to the user (OSGi bundles, DS API, Diagnostics via
> Karaf Shell etc.) but semantically not at all relevant (that is what the
> baseline api is for).
>
> Its works very well but its nowhere as convenient as it could be.
> Let me mention a few - knowing that we also work on some of them internally:
>
> - Limiting customisation to Maven is one thing (yeah.. everyone has its
> build ecosystem)
> - Karaf Boot seemed like a good start. But its went nowhere i think? [1]
> - Customizers don't care about pre-attached (opinionated) spring or
> enterprise repos that come (and change) with releases.
> - Branding seems like a niche thing. Yes there are knobs everywhere
> (webconsole, shell) but it could be addressed on a more systematic thing.
> Do other people care?
>
> Maybe this helps seeing Karaf not only as a product.
>
>
> [1] https://github.com/apache/karaf-boot
>
>
>
> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
>
> On Thu, Aug 16, 2018 at 10:48 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Toni,
>>
>> I know a fairly large set of users that use Karaf without knowing OSGi.
>>
>> That's why it's a polymorphic container: some use spring, some use OSGi,
>> some use blueprint, some use directly war, etc. There are several facet
>> of using Karaf.
>>
>> About the distribution, to be honest, I only know users of standard
>> distribution: either directly Karaf vanilla and then installing features
>> and their applications, or creating their own custom distribution
>> starting from the standard one. They don't necessary use the enterprise
>> features, it's more the standard distribution + their own features.
>>
>> One of the key part of Karaf is use friendly. That's the difference
>> starting from the framework. When you start from felix framework, it's
>> up to you to construct all: logging management, hot deployment, ...
>> Starting from Karaf it's a turnkey solution, having all user facing
>> aspects.
>> Karaf container and all its subprojects are really focused on user.
>>
>> Look at Decanter: it's tremendous simple solution but it does the job
>> and users just use it.
>>
>> Karaf is a "product project", it's not a SDK. It's a multi-purpose
>> runtime, powered by OSGi, but OSGi is not necessary the user facing model.
>>
>> That's why, as a "product project", I think it makes sense to have
>> regular release pace.
>>
>> Regards
>> JB
>>
>> On 16/08/2018 10:09, Toni Menzel wrote:
>>> As mentioned, here are some more thoughts on Karaf audience/usage.
>>>
>>> Do you know how Karaf users consume/use Karaf? This is important to get a
>>> good release cycle and granularity. (as teased by JB on this list
>> recently).
>>>
>>> Why i am mentioning that? Well,i always felt that Karaf (the container)
>> is
>>> a rather large thing with all its feature repos coming with it. I think
>>> thats why Karaf releases where coming rather slow in the past. (correct
>> or
>>> not?)
>>>
>>> *1. Karaf as an opinionated felix distro*
>>>
>>> This "batteries" included feature is (was?) a core selling point of Karaf
>>> but is this really how people use it?
>>> I know at least two larger customers who are baking their own Karaf
>>> distribution anyway based on the minimal profile.
>>>
>>> So i am asking, wouldn't it make sense to release the "base" runtime (say
>>> Felix+Karaf infrastructure like pax-url, feature system, configuration
>>> system) independently? Similar to what you get with Karaf minimal.
>>>
>>> Depending on how Karaf is used in the real world (do you know?), here are
>>> some radical thoughts on my/our personal usage:
>>>
>>> - Karaf Minimal becomes "Karaf Runtime" because its base unit you can
>>> put everything on top (even at runtime).
>>> - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
>>> kitchen-sink nature that is great when you want to tinker with
>>> Spring,Hibernate etc.
>>>
>>> Also, wouldn't it make sense to release the maven-plugin independently?
>>>
>>> Those changes might seem of no importance to Karaf insiders (because you
>>> get all of that already when building your own distro) but at least I
>> only
>>> found Karaf reasonable for a lot of usecases until i found out how to
>>> really only get the "runtime" part. Now i can say that for me Karaf is an
>>> opinionated felix distro (yes.. not only that but you get the point).
>>>
>>> *2. Karaf as polymorphic container*
>>>
>>> On the website Karaf is marketed as "Karaf can host any kind of
>>> applications: OSGi, Spring, WAR, and much more". Is that how people
>> really
>>> use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
>>> Every OSGi-savvy person recommends going DS, staying with OSGi spec
>>> standards and avoid War. - pun intended.
>>> Yeah, its great for demos but is it worth the effort? - also to keep this
>>> "working". And - from experience - i can tell that its also not a
>>> recommendable migration path. It sounds great but Hibernate and friends
>> are
>>> actually quite hostile to your OSGi framework instance introducing a lot
>>> more complexity into your system. And if even OSGi-savvy people have
>>> problems troubleshooting such cases, how should a team of beginners do
>> that?
>>>
>>> *3. Karaf as a better solution for Microservices*
>>>
>>> Guess i save this for another post, too easy to turn this into a rant.
>> Let
>>> me just say: i think Karaf is one of the few answers to the pervasive
>>> Microservice/Spring Boot ecosystem. But it is not obvious and people stay
>>> away from it because. Again, this COULD go very long, but it is not the
>>> right place.
>>>
>>> Any thoughts?
>>>
>>> * What is Developer Ergonomics <https://medium.com/rebaze>**? *
>>>
>>>
>>>
>>> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
>>> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Toni Menzel <to...@rebaze.com>.
Thanks everyone for your quick replies.
I see your point, JB. "One of the key part of Karaf is use friendly." thats
what i mean by "opinionated felix distro".
It may sound as a bad thing but i mean it as a feature: it puts "batteries"
included onto the osgi fw, has opinions how to configure stuff and where
logs go and how to do things you normally would expect from a complete
solution.
I would expect use-friendliness should be a feature of every product. Who
wants software that is hostile at you ? ;)
About "Product Project" well ok then. Thats the "Product Karaf" direction.
Good one!
Though, there might be room for improvements in the area "Karaf for SDK
Vendors"?
Treat the following as insight into how we use Karaf "not" as a product but
as the fabric for (business-) developers.
Our customers are building developer experiences (e.g. APIs for specific
problem domains) on top of Karaf Minimal.
1. We take Karaf Minimal and create custom distributions with all
technical features embedded, preconfigured & tested.This often includes a
lot of messy "OSGi-fied" legacy projects too.
2. We add business-centric/domain APIs to that distro. This is the
user-facing programming model. The only thing that leaks technically is the
fact that usually the model is being accessed as OSGi Services using DS.
But this is even exchangeable.We call the user-facing api "baseline api".
3. They get all this as an "SDK" which is made of a Docker Image,
Zip-Assembly and as an on-demand/per-user cloud service (all runtimes) and
Baseline-APIs artifacts (compile target).
4. They program against the baseline-api producing deliverables (usually
OSGi Bundles but could be anything accepted by the runtime).
5. Delivery is very customer specific, ranging from pre-baking "all
included" docker images or an app-store-like SaaS Model.
So we treat Karaf (and with it OSGi) as the internal fabric that is
technically exposed to the user (OSGi bundles, DS API, Diagnostics via
Karaf Shell etc.) but semantically not at all relevant (that is what the
baseline api is for).
Its works very well but its nowhere as convenient as it could be.
Let me mention a few - knowing that we also work on some of them internally:
- Limiting customisation to Maven is one thing (yeah.. everyone has its
build ecosystem)
- Karaf Boot seemed like a good start. But its went nowhere i think? [1]
- Customizers don't care about pre-attached (opinionated) spring or
enterprise repos that come (and change) with releases.
- Branding seems like a niche thing. Yes there are knobs everywhere
(webconsole, shell) but it could be addressed on a more systematic thing.
Do other people care?
Maybe this helps seeing Karaf not only as a product.
[1] https://github.com/apache/karaf-boot
*www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
<http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
On Thu, Aug 16, 2018 at 10:48 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Toni,
>
> I know a fairly large set of users that use Karaf without knowing OSGi.
>
> That's why it's a polymorphic container: some use spring, some use OSGi,
> some use blueprint, some use directly war, etc. There are several facet
> of using Karaf.
>
> About the distribution, to be honest, I only know users of standard
> distribution: either directly Karaf vanilla and then installing features
> and their applications, or creating their own custom distribution
> starting from the standard one. They don't necessary use the enterprise
> features, it's more the standard distribution + their own features.
>
> One of the key part of Karaf is use friendly. That's the difference
> starting from the framework. When you start from felix framework, it's
> up to you to construct all: logging management, hot deployment, ...
> Starting from Karaf it's a turnkey solution, having all user facing
> aspects.
> Karaf container and all its subprojects are really focused on user.
>
> Look at Decanter: it's tremendous simple solution but it does the job
> and users just use it.
>
> Karaf is a "product project", it's not a SDK. It's a multi-purpose
> runtime, powered by OSGi, but OSGi is not necessary the user facing model.
>
> That's why, as a "product project", I think it makes sense to have
> regular release pace.
>
> Regards
> JB
>
> On 16/08/2018 10:09, Toni Menzel wrote:
> > As mentioned, here are some more thoughts on Karaf audience/usage.
> >
> > Do you know how Karaf users consume/use Karaf? This is important to get a
> > good release cycle and granularity. (as teased by JB on this list
> recently).
> >
> > Why i am mentioning that? Well,i always felt that Karaf (the container)
> is
> > a rather large thing with all its feature repos coming with it. I think
> > thats why Karaf releases where coming rather slow in the past. (correct
> or
> > not?)
> >
> > *1. Karaf as an opinionated felix distro*
> >
> > This "batteries" included feature is (was?) a core selling point of Karaf
> > but is this really how people use it?
> > I know at least two larger customers who are baking their own Karaf
> > distribution anyway based on the minimal profile.
> >
> > So i am asking, wouldn't it make sense to release the "base" runtime (say
> > Felix+Karaf infrastructure like pax-url, feature system, configuration
> > system) independently? Similar to what you get with Karaf minimal.
> >
> > Depending on how Karaf is used in the real world (do you know?), here are
> > some radical thoughts on my/our personal usage:
> >
> > - Karaf Minimal becomes "Karaf Runtime" because its base unit you can
> > put everything on top (even at runtime).
> > - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
> > kitchen-sink nature that is great when you want to tinker with
> > Spring,Hibernate etc.
> >
> > Also, wouldn't it make sense to release the maven-plugin independently?
> >
> > Those changes might seem of no importance to Karaf insiders (because you
> > get all of that already when building your own distro) but at least I
> only
> > found Karaf reasonable for a lot of usecases until i found out how to
> > really only get the "runtime" part. Now i can say that for me Karaf is an
> > opinionated felix distro (yes.. not only that but you get the point).
> >
> > *2. Karaf as polymorphic container*
> >
> > On the website Karaf is marketed as "Karaf can host any kind of
> > applications: OSGi, Spring, WAR, and much more". Is that how people
> really
> > use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
> > Every OSGi-savvy person recommends going DS, staying with OSGi spec
> > standards and avoid War. - pun intended.
> > Yeah, its great for demos but is it worth the effort? - also to keep this
> > "working". And - from experience - i can tell that its also not a
> > recommendable migration path. It sounds great but Hibernate and friends
> are
> > actually quite hostile to your OSGi framework instance introducing a lot
> > more complexity into your system. And if even OSGi-savvy people have
> > problems troubleshooting such cases, how should a team of beginners do
> that?
> >
> > *3. Karaf as a better solution for Microservices*
> >
> > Guess i save this for another post, too easy to turn this into a rant.
> Let
> > me just say: i think Karaf is one of the few answers to the pervasive
> > Microservice/Spring Boot ecosystem. But it is not obvious and people stay
> > away from it because. Again, this COULD go very long, but it is not the
> > right place.
> >
> > Any thoughts?
> >
> > * What is Developer Ergonomics <https://medium.com/rebaze>**? *
> >
> >
> >
> > *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> > <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Toni,
I know a fairly large set of users that use Karaf without knowing OSGi.
That's why it's a polymorphic container: some use spring, some use OSGi,
some use blueprint, some use directly war, etc. There are several facet
of using Karaf.
About the distribution, to be honest, I only know users of standard
distribution: either directly Karaf vanilla and then installing features
and their applications, or creating their own custom distribution
starting from the standard one. They don't necessary use the enterprise
features, it's more the standard distribution + their own features.
One of the key part of Karaf is use friendly. That's the difference
starting from the framework. When you start from felix framework, it's
up to you to construct all: logging management, hot deployment, ...
Starting from Karaf it's a turnkey solution, having all user facing aspects.
Karaf container and all its subprojects are really focused on user.
Look at Decanter: it's tremendous simple solution but it does the job
and users just use it.
Karaf is a "product project", it's not a SDK. It's a multi-purpose
runtime, powered by OSGi, but OSGi is not necessary the user facing model.
That's why, as a "product project", I think it makes sense to have
regular release pace.
Regards
JB
On 16/08/2018 10:09, Toni Menzel wrote:
> As mentioned, here are some more thoughts on Karaf audience/usage.
>
> Do you know how Karaf users consume/use Karaf? This is important to get a
> good release cycle and granularity. (as teased by JB on this list recently).
>
> Why i am mentioning that? Well,i always felt that Karaf (the container) is
> a rather large thing with all its feature repos coming with it. I think
> thats why Karaf releases where coming rather slow in the past. (correct or
> not?)
>
> *1. Karaf as an opinionated felix distro*
>
> This "batteries" included feature is (was?) a core selling point of Karaf
> but is this really how people use it?
> I know at least two larger customers who are baking their own Karaf
> distribution anyway based on the minimal profile.
>
> So i am asking, wouldn't it make sense to release the "base" runtime (say
> Felix+Karaf infrastructure like pax-url, feature system, configuration
> system) independently? Similar to what you get with Karaf minimal.
>
> Depending on how Karaf is used in the real world (do you know?), here are
> some radical thoughts on my/our personal usage:
>
> - Karaf Minimal becomes "Karaf Runtime" because its base unit you can
> put everything on top (even at runtime).
> - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
> kitchen-sink nature that is great when you want to tinker with
> Spring,Hibernate etc.
>
> Also, wouldn't it make sense to release the maven-plugin independently?
>
> Those changes might seem of no importance to Karaf insiders (because you
> get all of that already when building your own distro) but at least I only
> found Karaf reasonable for a lot of usecases until i found out how to
> really only get the "runtime" part. Now i can say that for me Karaf is an
> opinionated felix distro (yes.. not only that but you get the point).
>
> *2. Karaf as polymorphic container*
>
> On the website Karaf is marketed as "Karaf can host any kind of
> applications: OSGi, Spring, WAR, and much more". Is that how people really
> use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
> Every OSGi-savvy person recommends going DS, staying with OSGi spec
> standards and avoid War. - pun intended.
> Yeah, its great for demos but is it worth the effort? - also to keep this
> "working". And - from experience - i can tell that its also not a
> recommendable migration path. It sounds great but Hibernate and friends are
> actually quite hostile to your OSGi framework instance introducing a lot
> more complexity into your system. And if even OSGi-savvy people have
> problems troubleshooting such cases, how should a team of beginners do that?
>
> *3. Karaf as a better solution for Microservices*
>
> Guess i save this for another post, too easy to turn this into a rant. Let
> me just say: i think Karaf is one of the few answers to the pervasive
> Microservice/Spring Boot ecosystem. But it is not obvious and people stay
> away from it because. Again, this COULD go very long, but it is not the
> right place.
>
> Any thoughts?
>
> * What is Developer Ergonomics <https://medium.com/rebaze>**? *
>
>
>
> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Karaf target audience and release granularity
Posted by Robert Varga <ni...@hq.sk>.
On 17/08/18 15:30, Jean-Baptiste Onofré wrote:
> Hi Robert,
Hello JB,
> thanks for your feedback, and I fully agree with you.
>
> For the release, it's largely my fault for 4.2.1: I wanted to include
> too much fixes, upgrades and new features. My bad, and apologize for
> that. That's why I wanted to propose to reduce scope of the releases and
> do it on a regular pace, much more predictable to users/devs like you.
>
> For the changes, we are now much more "strict" in the changes we are
> doing. Any breaking changes is not allowed on a minor release.
That is absolutely fantastic.
> For the documentation, we started a huge work on this one. You can
> already see the user guide is largely better than before IMHO. Now the
> target is on the dev guide and related examples.
Awesome, that will help us immensely.
> I see your point the way you are "packaging" the features. Any reason
> why you don't manage your features repository by hand ?
There are couple of reasons for that, actually, some of which may be
historical, but have gotten us where we are. Given the history, there is
reluctance to do another big migration unless the outcome is guaranteed
to work and be easier to use than we have now.
The first problem comes from the fact that OpenDaylight is a collection
of projects, each with its own release cycle and versioning. Each of
them focuses on a problem area -- so to get OpenDaylight "core" you need
to assemble 4 projects, for "platform" it is 6-8 projects and the Karaf
distro available for download contains something like 16-20 projects.
The end result needs to be version-converged, obviously.
Hence we need to communicate versions between projects and retain strong
version requirements. This is done through bill-of-material poms
published by an upstream project and ingested by downstreams as a
scope=import dependency. We therefore need to pick up versions used in
features -- and use of properties is not an acceptable solution.
To address this, we used to have hand-written feature.xml templates,
which we processed with a rather arcane script
(https://github.com/opendaylight/odlparent/blob/stable/lithium/features-parent/pom.xml#L75).
The second problem is that the developers found it somewhere between
unfriendly and downright hostile, as features did not "just work", but
tended to fail on our SFT with a bundle resolution error of various
complexity -- ranging from simple missing imports to rather arcane class
mismatches, depending what sort of mistake the dev made.
Normal folk get scared by these and if they cannot solve them easily
they just walk away. When this is coupled with the unfamiliar paradigms
used in OpenDaylight proper, this can easily lead to the perception that
OpenDaylight/Karaf is not something mere mortals can use :(
Our hope was that we could solve this usability problem by resorting to
generated features during our migration to Karaf-4.0.x. This has the
problem of massive over-inclusion, resulting in features which
explicitly pull in bundles observed at compile-time, even when those
bundles are provided in a feature somewhere else. The generated features
are ugly, but 95-99% of the time they Just Work(tm). This allows people
to get started quickly, with the features getting eventually cleaned up.
Over the course of past of two years we (well, mostly Stephen Kitt) have
contributed the missing bits to the karaf plugin and configured our
build system in ways which make this work reasonably well.
Now we are coming to complete the circle, where for some projects we are
considering hand-written features, but to justify that migration, we
need solid documentation on how to use features to their full extent.
Even then, though, the main challenge remains: how can we on-board a
developer, who has never heard of OSGi nor features, so she can work on
their code rather than to going through a bootcamp of OSGi/Karaf pain :(
> Anyway, 4.1.6 has been released and 4.2.1 will be on vote tonight.
> Starting for there, I will send the release agenda with a release every
> two months for both Karaf Container but also the subprojects.
Great, we are targeting both those versions for inclusion in our current
release trains. I am looking for those agenda emails!
Thanks,
Robert
Re: Karaf target audience and release granularity
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Robert,
thanks for your feedback, and I fully agree with you.
For the release, it's largely my fault for 4.2.1: I wanted to include
too much fixes, upgrades and new features. My bad, and apologize for
that. That's why I wanted to propose to reduce scope of the releases and
do it on a regular pace, much more predictable to users/devs like you.
For the changes, we are now much more "strict" in the changes we are
doing. Any breaking changes is not allowed on a minor release.
For the documentation, we started a huge work on this one. You can
already see the user guide is largely better than before IMHO. Now the
target is on the dev guide and related examples.
I see your point the way you are "packaging" the features. Any reason
why you don't manage your features repository by hand ?
Anyway, 4.1.6 has been released and 4.2.1 will be on vote tonight.
Starting for there, I will send the release agenda with a release every
two months for both Karaf Container but also the subprojects.
Thanks !
Regards
JB
On 17/08/2018 15:12, Robert Varga wrote:
> 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
>
Re: Karaf target audience and release granularity
Posted by Robert Varga <ni...@hq.sk>.
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
Re: Karaf target audience and release granularity
Posted by "Jamie G." <ja...@gmail.com>.
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.
On Thu, Aug 16, 2018 at 5:40 AM Toni Menzel <to...@rebaze.com> wrote:
>
> As mentioned, here are some more thoughts on Karaf audience/usage.
>
> Do you know how Karaf users consume/use Karaf? This is important to get a
> good release cycle and granularity. (as teased by JB on this list recently).
>
> Why i am mentioning that? Well,i always felt that Karaf (the container) is
> a rather large thing with all its feature repos coming with it. I think
> thats why Karaf releases where coming rather slow in the past. (correct or
> not?)
>
> *1. Karaf as an opinionated felix distro*
>
> This "batteries" included feature is (was?) a core selling point of Karaf
> but is this really how people use it?
> I know at least two larger customers who are baking their own Karaf
> distribution anyway based on the minimal profile.
>
> So i am asking, wouldn't it make sense to release the "base" runtime (say
> Felix+Karaf infrastructure like pax-url, feature system, configuration
> system) independently? Similar to what you get with Karaf minimal.
>
> Depending on how Karaf is used in the real world (do you know?), here are
> some radical thoughts on my/our personal usage:
>
> - Karaf Minimal becomes "Karaf Runtime" because its base unit you can
> put everything on top (even at runtime).
> - Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
> kitchen-sink nature that is great when you want to tinker with
> Spring,Hibernate etc.
>
> Also, wouldn't it make sense to release the maven-plugin independently?
>
> Those changes might seem of no importance to Karaf insiders (because you
> get all of that already when building your own distro) but at least I only
> found Karaf reasonable for a lot of usecases until i found out how to
> really only get the "runtime" part. Now i can say that for me Karaf is an
> opinionated felix distro (yes.. not only that but you get the point).
>
> *2. Karaf as polymorphic container*
>
> On the website Karaf is marketed as "Karaf can host any kind of
> applications: OSGi, Spring, WAR, and much more". Is that how people really
> use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
> Every OSGi-savvy person recommends going DS, staying with OSGi spec
> standards and avoid War. - pun intended.
> Yeah, its great for demos but is it worth the effort? - also to keep this
> "working". And - from experience - i can tell that its also not a
> recommendable migration path. It sounds great but Hibernate and friends are
> actually quite hostile to your OSGi framework instance introducing a lot
> more complexity into your system. And if even OSGi-savvy people have
> problems troubleshooting such cases, how should a team of beginners do that?
>
> *3. Karaf as a better solution for Microservices*
>
> Guess i save this for another post, too easy to turn this into a rant. Let
> me just say: i think Karaf is one of the few answers to the pervasive
> Microservice/Spring Boot ecosystem. But it is not obvious and people stay
> away from it because. Again, this COULD go very long, but it is not the
> right place.
>
> Any thoughts?
>
> * What is Developer Ergonomics <https://medium.com/rebaze>**? *
>
>
>
> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*