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 <shu...@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é <j...@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 <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
