karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shu...@apache.org>
Subject Re: [DISCUSS] Launching the kloud initiative
Date Wed, 13 Feb 2019 10:04:37 GMT
+1 on promoting Karaf. May I remind you I produced a while ago a lot
of resources comparing Karaf to other frameworks solutions?

https://docs.google.com/spreadsheets/d/1Js5qTXXugEOsp-5kUYoUbCKP1xt1dUx8efWZcGbm6C4/edit#gid=0
https://docs.google.com/document/d/1b1aJ_qimFxPxD9BDtaq21sW_h43kWUXrLVTWAFR_Coc/edit#heading=h.3uzgwjymutz
https://docs.google.com/document/d/1cZp-KymYOVgpBiHVPdLAYfKY81U_LzfqVYCIcVd2Mfg/edit#heading=h.9xhre7dovs0q
https://docs.google.com/document/d/1e4vvXhTNMaAbb7UgDSgmRjvVHp_nm981ztw33k0kHN8/edit#heading=h.2jt36cq65nll

Of course, these resources can be improved, especially in light of the
kloud initiative, but I think that it would help promote Karaf more
aggressively.

Regards,
  Serge...

On Wed, Feb 13, 2019 at 9:06 AM Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
>
> Good point Serge.
>
> The huge advantage of Karaf is our "polymorphic" approach: we can
> address lot of different packaging, use cases, etc.
>
> So, update is a key thing as well (more for dynamic approach than static
> I think).
>
> I forgot to mention one area where we would need help: spread the word
> and advertising. With the kloud initiative, I think we can seduce more
> users, but they have to find Karaf and what they can do with it and how
> Karaf can help them.
>
> I created new Jira yesterday evening, and now I'm starting from PoC that
> you will be able to see as PRs soon.
>
> Thanks for your enthusiasm and your interest in Karaf !
>
> Let's build the "new" Karaf ;)
>
> Regards
> JB
>
> On 13/02/2019 08:29, Serge Huber wrote:
> > +1
> >
> > I really like this project, but I think we should also be careful to
> > really leverage Karaf's strengths compared to other frameworks (such
> > as Spring or others).
> >
> > I have a millions things that come to mind, how to address :
> > - upgrades
> > - rolling upgrades
> > - leveraging Karaf to avoid building lots of containers and use
> > instead OSGi to reduce the memory / CPU footprint
> > - configuration of containers (passed as env or even centralized ?)
> >
> > There are also some very interesting developments coming to the JDK
> > (in JDK 12) such as Project Loom that could help scale Karaf to
> > millions of network connections on single instances without the need
> > for NIO.
> >
> > We were talking in another thread about having a very thin OS-layer on
> > top of Karaf to have baremetal performance and I think this could be
> > very interesting in a cloud setup as well.
> >
> > Anyway, I'm just throwing ideas here, hope you don't mind :)
> >
> > cheers,
> >   Serge
> >
> > On Mon, Feb 11, 2019 at 2:11 PM David Daniel
> > <david.daniel.1979@gmail.com> wrote:
> >>
> >> Thank you,
> >>   I would also be curious if it is possible to work to align some features
> >> changes to be compatible with the osgi feature spec.
> >> https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf  It
> >> might be possible to bridge some of the gap between bnd and karaf.  I love
> >> things about both frameworks and would be super excited if they could work
> >> together.
> >>
> >> David
> >>
> >> On Mon, Feb 11, 2019 at 7:01 AM Jean-Baptiste Onofré <jb@nanthrax.net>
> >> wrote:
> >>
> >>> Thanks for your feedback David, nice idea about jlink, I have to
> >>> investigate a little about it, but definitely interesting.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 11/02/2019 12:52, David Daniel wrote:
> >>>> I really like the idea of the static build and features in code.  I
think
> >>>> the jdk is making great strides in getting java running well on docker
> >>>> java 9 jlink for small images that can be copied and spun up quickly
> >>>> java 10 defaults improvements https://aboullaite.me/docker-java-10/
> >>>> portola for running java on musl (alpine without glibc)
> >>>> https://openjdk.java.net/projects/portola/
> >>>> loom is coming for not spinning off a ton of threads
> >>>> If at all possible I would love to be able to build a minimal karaf
> >>>> distribution with jlink from java module files that were generated from
> >>> the
> >>>> karaf resolver.  I think this might be a little much though and don't
> >>> even
> >>>> know if it is possible.  Just something that might be able to be looked
> >>> at
> >>>> while the code is being written.
> >>>>
> >>>> David
> >>>>
> >>>>
> >>>> On Mon, Feb 11, 2019 at 1:57 AM Jean-Baptiste Onofré <jb@nanthrax.net>
> >>>> wrote:
> >>>>
> >>>>> Hi guys,
> >>>>>
> >>>>> As we now have released Karaf runtime 4.2.3 and started 4.3.x, I
think
> >>>>> it's time to discuss and move forward "concretely" about the "kloud"
> >>>>> (Karaf for the Cloud) initiative.
> >>>>>
> >>>>> I think the first approach is focused on the developers and devops.
I
> >>>>> created the following Jira:
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/KARAF-5923
> >>>>> https://issues.apache.org/jira/browse/KARAF-6148
> >>>>> https://issues.apache.org/jira/browse/KARAF-6149
> >>>>> https://issues.apache.org/jira/browse/KARAF-6150
> >>>>>
> >>>>> The idea is really to simplify the features generation and distribution
> >>>>> packaging.
> >>>>>
> >>>>> For the features generation, I'm thinking on annotations directly
in the
> >>>>> code (in package-info.java for instance) describing the features
needed
> >>>>> by the application. The annotations scanner could then create the
> >>>>> features XML using the code itself and the annotations. That would
allow
> >>>>> us to not relay on Maven and be able to support CLI/Gradle/Maven.
In the
> >>>>> case where the user uses Maven, we could better leverage Maven to
get
> >>>>> some details. The idea is to especially easily create features XML
to
> >>>>> build "static" runtime (that make sense for the cloud).
> >>>>>
> >>>>> After the features XML generation, we should have a easier way to
build
> >>>>> a distribution. We also have to provide multiple "packaging output"
like
> >>>>> archives (zip/tar.gz), uber jar (embedding karaf and user application),
> >>>>> docker image, openimage, kubernetes meta, ...
> >>>>> The idea is to have a ready to go packaging for the cloud.
> >>>>>
> >>>>> For the cloud perspective, the distribution should be
> >>>>> "immutable/static". Currently, the resolver we have is great for
> >>>>> "dynamic" deployment but could be painful for static one (dealing
with
> >>>>> refresh, multiple versions resolution, etc).
> >>>>> I'm proposing to create kind of "static" resolver
> >>>>> (https://issues.apache.org/jira/browse/KARAF-6147) directly taking
boot
> >>>>> features and installing straight forward what's defined in the features.
> >>>>> It should result with a more "predictable" behavior, really helpful
from
> >>>>> a cloud perspective.
> >>>>>
> >>>>> Finally, I created some Jira about general improvements for the
cloud
> >>>>> and docker:
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/KARAF-6111
> >>>>> https://issues.apache.org/jira/browse/KARAF-4609
> >>>>>
> >>>>> I think you got the overall idea: dramatically simplify creation
of
> >>>>> distribution packaging karaf with user application (for developer),
> >>>>> simplify the packaging outputs and bootstrapping on cloud (for devops).
> >>>>>
> >>>>> If you think it could be helpful to have a doc on confluence about
that,
> >>>>> please let me know I will create it.
> >>>>>
> >>>>> We all know that Karaf is an amazing runtime. To convince more and
more
> >>>>> users and give a new dimension to Karaf, I really think that the
"kloud
> >>>>> initiative" is a must have. We will have a runtime that can address
both
> >>>>> static and dynamic bootstrapping approach, one runtime for multiple
> >>>>> services or one runtime per service, etc.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>> --
> >>>>> 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
> >>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Mime
View raw message