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 12:29:20 GMT
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
View raw message