karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSS] Launching the kloud initiative
Date Wed, 13 Feb 2019 11:49:56 GMT
I also think configuration from env variables is one of the most important
things to solve. Docker images and Kubernetes deployment descriptors often
look horribly complicated when this is not solved well.

I have seen two interesting attempts at this:
1. The configurer from Peter Kriens. It allows to override any OSGi config
from the command line and I think it also allows using env variables. (see
https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider
)
2. Dropwizard configuration style. There you have a configuration in yaml
form but you can use placeholders with defaults that can feed from env
variables. (See
https://www.dropwizard.io/0.9.3/docs/manual/core.html#environment-variables
).

Especially the dropwizard style looks really good.
One thing to solve there is how to bridge the gap to OSGi configs that are
always a set of properties vs spring boot or similar configs that are a
flat list of properties. The tree structure of yaml or json might help us
there.

Christian

Am Mi., 13. Feb. 2019 um 08:29 Uhr schrieb Serge Huber <shuber@apache.org>:

> +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
> > >
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message