From dev-return-13478-archive-asf-public=cust-asf.ponee.io@karaf.apache.org Thu Feb 14 09:21:56 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id DDC04180626 for ; Thu, 14 Feb 2019 10:21:55 +0100 (CET) Received: (qmail 41205 invoked by uid 500); 14 Feb 2019 09:21:54 -0000 Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@karaf.apache.org Delivered-To: mailing list dev@karaf.apache.org Received: (qmail 41194 invoked by uid 99); 14 Feb 2019 09:21:54 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2019 09:21:54 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id A7E1CC5A32 for ; Thu, 14 Feb 2019 09:21:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id QutPkRfGumyQ for ; Thu, 14 Feb 2019 09:21:51 +0000 (UTC) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id DD894623B8 for ; Thu, 14 Feb 2019 09:21:50 +0000 (UTC) X-Originating-IP: 82.64.90.43 Received: from [192.168.134.110] (unknown [82.64.90.43]) (Authenticated sender: jb@nanthrax.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 0D278240014 for ; Thu, 14 Feb 2019 09:21:49 +0000 (UTC) Subject: Re: [DISCUSS] Launching the kloud initiative To: dev@karaf.apache.org References: <5cc8f83e-1453-a6ae-1011-c97a4e27008a@nanthrax.net> <0848fa4a-4cac-270b-3e14-272184ce5452@nanthrax.net> <088EDEE3-0783-4EB4-8AF7-369DCB82337E@jahia.com> From: =?UTF-8?Q?Jean-Baptiste_Onofr=c3=a9?= Message-ID: <5bbc56ab-d216-76f0-38d0-2a4af6b43dc5@nanthrax.net> Date: Thu, 14 Feb 2019 10:21:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <088EDEE3-0783-4EB4-8AF7-369DCB82337E@jahia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 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é 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 : >>>>> >>>>> +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 >>>>> 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é >>>>>> 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