karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSS] Launching the kloud initiative
Date Wed, 13 Feb 2019 10:21:33 GMT
Yes, thanks for that Serge.

We started to prepare a PR on the karaf-site using your testimonial:


Feel free to update the PR ;)


On 13/02/2019 11:04, Serge Huber wrote:
> +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
>>>>> 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
>>>>> 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
>>>>>>> (Karaf for the Cloud) initiative.
>>>>>>> I think the first approach is focused on the developers and devops.
>>>>>>> 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
>>>>>>> by the application. The annotations scanner could then create
>>>>>>> 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"
>>>>>>> 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
>>>>>>> "dynamic" deployment but could be painful for static one (dealing
>>>>>>> refresh, multiple versions resolution, etc).
>>>>>>> I'm proposing to create kind of "static" resolver
>>>>>>> (https://issues.apache.org/jira/browse/KARAF-6147) directly taking
>>>>>>> features and installing straight forward what's defined in the
>>>>>>> It should result with a more "predictable" behavior, really helpful
>>>>>>> a cloud perspective.
>>>>>>> Finally, I created some Jira about general improvements for the
>>>>>>> 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
>>>>>>> distribution packaging karaf with user application (for developer),
>>>>>>> simplify the packaging outputs and bootstrapping on cloud (for
>>>>>>> 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
>>>>>>> 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

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message