karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shu...@jahia.com>
Subject Re: [DISCUSS] Launching the kloud initiative
Date Thu, 14 Feb 2019 07:29:14 GMT
Just read this:

https://www.linkedin.com/pulse/serverless-framework-michael-vargas

What would be perfect is to be able to replace the Nodejs runtime in this config with Karaf

I think that Karaf makes a ton of sense as a « server less » runtime. You build your features
and don’t care on what hardware they run or how they are deployed.

Wdyt ?

Regards,
  Serge

T +41 22 361 3424

9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a leading User
Experience Platform (UXP) for Digital Transformation.

> Le 13 févr. 2019 à 14:45, Serge Huber <shuber@apache.org> a écrit :
> 
> My thinking is that the env variables would override, but if you
> change during runtime a value it could still change (and be
> serialized), or we could somehow prevent that. But on next start the
> env override would apply again anyway.
> 
> It shouldn't be difficult to make this behavior configurable anyway,
> but it is a huge requirement for Docker support, and possibly other
> containers might have similar requirements.
> 
> Regards,
>  Serge...
> 
>> On Wed, Feb 13, 2019 at 1:29 PM Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
>> 
>> Hi Christian
>> 
>> I already started a PoC using a decorator to ConfigAdmin to
>> "inject/override" configuration from plugable backend (like env, like
>> AWS service, ...). It use a converter to map the "backend" config to
>> config admin style.
>> 
>> I will share my PoC on PR asap.
>> 
>> Regards
>> JB
>> 
>>> On 13/02/2019 12:49, Christian Schneider wrote:
>>> 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
>>>>>> 
>>>> 
>>> 
>>> 
>> 
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message