From dev-return-13464-archive-asf-public=cust-asf.ponee.io@karaf.apache.org Wed Feb 13 11:50:16 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 4D06C180674 for ; Wed, 13 Feb 2019 12:50:15 +0100 (CET) Received: (qmail 77070 invoked by uid 500); 13 Feb 2019 11:50:14 -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 77057 invoked by uid 99); 13 Feb 2019 11:50:13 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Feb 2019 11:50:13 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 56B04C1BB2 for ; Wed, 13 Feb 2019 11:50:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.251 X-Spam-Level: ** X-Spam-Status: No, score=2.251 tagged_above=-999 required=6.31 tests=[FREEMAIL_ENVFROM_END_DIGIT=0.25, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id PmnFUrBQ3oRn for ; Wed, 13 Feb 2019 11:50:10 +0000 (UTC) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 864CC5F624 for ; Wed, 13 Feb 2019 11:50:09 +0000 (UTC) Received: by mail-lj1-f174.google.com with SMTP id v16so1707909ljg.13 for ; Wed, 13 Feb 2019 03:50:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Oe4oZgkU7kHa9iGtQnN9ADarYTy9WFSAVMYBcktUTYY=; b=JQSLva7/xv2495EZ03VZZ+bet+K67fCNxCrqQ5hruxKCKZw3r9u2c5xKpYcYL4gmkV 4+hpJGR5M5B0KMSk8h6lIht6y0MGl81WFhSBhZGucA8RtKOl6ySUmPdEgd9Dw87dKScU VPsEzDJi2FG5ijDt+NJnkuu4yRy9KgM3YynPEH8IMc3p1bOU5EY8OtS8HdH16VgMluYf 8/enD8VNfJ4lUZJkvWiejd8Ro7+qj5uYQDOdZ7ecxq5GyjA0p9HRBpdWpxTwDXtUNTZY 9DxUDyKrnTnbsLTZYGVOtVZcNs9P2n5q3FVWYy9rUQL++BOHr23Hy6RR1N9BWxO+BWq4 Glcw== X-Gm-Message-State: AHQUAubRLa4dshecwMhByBwit/NuGDWeHUaR5BwqkvvLtSMduryN/36y GavnHLITnodW+NmKCDyooMi/0lyQhioTQrHUy4E7lATSHtJdAQ== X-Google-Smtp-Source: AHgI3IY8/DREHKRWyfF43eZRfxc7FkTBI4vQ470HWezoA6xWGo4YF0aH5TCTbRUsJ3Z2UC86T8+Ab8jCaQLLc196Bbs= X-Received: by 2002:a2e:9e16:: with SMTP id e22-v6mr81656ljk.4.1550058607712; Wed, 13 Feb 2019 03:50:07 -0800 (PST) MIME-Version: 1.0 References: <5cc8f83e-1453-a6ae-1011-c97a4e27008a@nanthrax.net> <0848fa4a-4cac-270b-3e14-272184ce5452@nanthrax.net> In-Reply-To: From: Christian Schneider Date: Wed, 13 Feb 2019 12:49:56 +0100 Message-ID: Subject: Re: [DISCUSS] Launching the kloud initiative To: dev@karaf.apache.org Content-Type: multipart/alternative; boundary="000000000000b19f270581c524b0" --000000000000b19f270581c524b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.confi= gurer.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=C3=A9 > > 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 quickl= y > > > > 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=C3=A9 < > 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 "klou= d" > > > >> (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 helpfu= l > 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 o= f > > > >> 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 addres= s > both > > > >> static and dynamic bootstrapping approach, one runtime for multipl= e > > > >> services or one runtime per service, etc. > > > >> > > > >> Thoughts ? > > > >> > > > >> Regards > > > >> JB > > > >> -- > > > >> Jean-Baptiste Onofr=C3=A9 > > > >> jbonofre@apache.org > > > >> http://blog.nanthrax.net > > > >> Talend - http://www.talend.com > > > >> > > > > > > > > > > -- > > > Jean-Baptiste Onofr=C3=A9 > > > jbonofre@apache.org > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > --=20 --=20 Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com --000000000000b19f270581c524b0--