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 07:29:20 GMT
+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
> >

Mime
View raw message