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 Thu, 14 Feb 2019 09:21:49 GMT
Fully agree, that's the purpose of the "karaf direct runtime" (you focus
on your code and Karaf tooling build the runtime packaging) IMHO.

Regards
JB

On 14/02/2019 08:29, Serge Huber wrote:
> 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
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message