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 <shu...@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.1...@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é <j...@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é < >> j...@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é >>>>>> jbono...@apache.org >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>>> >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >> > > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
