You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2019/02/11 06:57:06 UTC

[DISCUSS] Launching the kloud initiative

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

Re: [DISCUSS] Launching the kloud initiative

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <sh...@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é <jb...@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 <sh...@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
>>>>> <da...@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
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Launching the kloud initiative

Posted by Serge Huber <sh...@jahia.com>.
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 <sh...@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é <jb...@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 <sh...@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
>>>> <da...@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

Re: [DISCUSS] Launching the kloud initiative

Posted by Serge Huber <sh...@apache.org>.
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é <jb...@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 <sh...@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
> >> <da...@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

Re: [DISCUSS] Launching the kloud initiative

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <sh...@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
>> <da...@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

Re: [DISCUSS] Launching the kloud initiative

Posted by Francois Papon <fr...@openobject.fr>.
Hi Christian,

The configuration keys loaded with env variables will not be able to be
changed at runtime, right?

So we are talking about bootstrap properties only?

regards,

François Papon
fpapon@apache.org

Le 13/02/2019 à 15:49, Christian Schneider a écrit :
> 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 <sh...@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
>> <da...@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
>>>>
>

Re: [DISCUSS] Launching the kloud initiative

Posted by Christian Schneider <ch...@die-schneider.net>.
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 <sh...@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
> <da...@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
> > >
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [DISCUSS] Launching the kloud initiative

Posted by Francois Papon <fr...@openobject.fr>.
Hi Serge,

I pushed a PR based on your resources for the Karaf site ;)

https://github.com/apache/karaf-site/pull/36

Regards,

François Papon
fpapon@apache.org

Le 13/02/2019 à 14:04, Serge Huber a écrit :
> +1 on promoting Karaf. May I remind you I produced a while ago a lot
> of resources comparing Karaf to other frameworks solutions?
>
> https://docs.google.com/spreadsheets/d/1Js5qTXXugEOsp-5kUYoUbCKP1xt1dUx8efWZcGbm6C4/edit#gid=0
> https://docs.google.com/document/d/1b1aJ_qimFxPxD9BDtaq21sW_h43kWUXrLVTWAFR_Coc/edit#heading=h.3uzgwjymutz
> https://docs.google.com/document/d/1cZp-KymYOVgpBiHVPdLAYfKY81U_LzfqVYCIcVd2Mfg/edit#heading=h.9xhre7dovs0q
> https://docs.google.com/document/d/1e4vvXhTNMaAbb7UgDSgmRjvVHp_nm981ztw33k0kHN8/edit#heading=h.2jt36cq65nll
>
> Of course, these resources can be improved, especially in light of the
> kloud initiative, but I think that it would help promote Karaf more
> aggressively.
>
> Regards,
>   Serge...
>
> On Wed, Feb 13, 2019 at 9:06 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Good point Serge.
>>
>> The huge advantage of Karaf is our "polymorphic" approach: we can
>> address lot of different packaging, use cases, etc.
>>
>> So, update is a key thing as well (more for dynamic approach than static
>> I think).
>>
>> I forgot to mention one area where we would need help: spread the word
>> and advertising. With the kloud initiative, I think we can seduce more
>> users, but they have to find Karaf and what they can do with it and how
>> Karaf can help them.
>>
>> I created new Jira yesterday evening, and now I'm starting from PoC that
>> you will be able to see as PRs soon.
>>
>> Thanks for your enthusiasm and your interest in Karaf !
>>
>> Let's build the "new" Karaf ;)
>>
>> Regards
>> JB
>>
>> On 13/02/2019 08:29, Serge Huber wrote:
>>> +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
>>> <da...@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

Re: [DISCUSS] Launching the kloud initiative

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, thanks for that Serge.

We started to prepare a PR on the karaf-site using your testimonial:

https://github.com/apache/karaf-site/pull/36

Feel free to update the PR ;)

Regards
JB

On 13/02/2019 11:04, Serge Huber wrote:
> +1 on promoting Karaf. May I remind you I produced a while ago a lot
> of resources comparing Karaf to other frameworks solutions?
> 
> https://docs.google.com/spreadsheets/d/1Js5qTXXugEOsp-5kUYoUbCKP1xt1dUx8efWZcGbm6C4/edit#gid=0
> https://docs.google.com/document/d/1b1aJ_qimFxPxD9BDtaq21sW_h43kWUXrLVTWAFR_Coc/edit#heading=h.3uzgwjymutz
> https://docs.google.com/document/d/1cZp-KymYOVgpBiHVPdLAYfKY81U_LzfqVYCIcVd2Mfg/edit#heading=h.9xhre7dovs0q
> https://docs.google.com/document/d/1e4vvXhTNMaAbb7UgDSgmRjvVHp_nm981ztw33k0kHN8/edit#heading=h.2jt36cq65nll
> 
> Of course, these resources can be improved, especially in light of the
> kloud initiative, but I think that it would help promote Karaf more
> aggressively.
> 
> Regards,
>   Serge...
> 
> On Wed, Feb 13, 2019 at 9:06 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> Good point Serge.
>>
>> The huge advantage of Karaf is our "polymorphic" approach: we can
>> address lot of different packaging, use cases, etc.
>>
>> So, update is a key thing as well (more for dynamic approach than static
>> I think).
>>
>> I forgot to mention one area where we would need help: spread the word
>> and advertising. With the kloud initiative, I think we can seduce more
>> users, but they have to find Karaf and what they can do with it and how
>> Karaf can help them.
>>
>> I created new Jira yesterday evening, and now I'm starting from PoC that
>> you will be able to see as PRs soon.
>>
>> Thanks for your enthusiasm and your interest in Karaf !
>>
>> Let's build the "new" Karaf ;)
>>
>> Regards
>> JB
>>
>> On 13/02/2019 08:29, Serge Huber wrote:
>>> +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
>>> <da...@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

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Launching the kloud initiative

Posted by Serge Huber <sh...@apache.org>.
+1 on promoting Karaf. May I remind you I produced a while ago a lot
of resources comparing Karaf to other frameworks solutions?

https://docs.google.com/spreadsheets/d/1Js5qTXXugEOsp-5kUYoUbCKP1xt1dUx8efWZcGbm6C4/edit#gid=0
https://docs.google.com/document/d/1b1aJ_qimFxPxD9BDtaq21sW_h43kWUXrLVTWAFR_Coc/edit#heading=h.3uzgwjymutz
https://docs.google.com/document/d/1cZp-KymYOVgpBiHVPdLAYfKY81U_LzfqVYCIcVd2Mfg/edit#heading=h.9xhre7dovs0q
https://docs.google.com/document/d/1e4vvXhTNMaAbb7UgDSgmRjvVHp_nm981ztw33k0kHN8/edit#heading=h.2jt36cq65nll

Of course, these resources can be improved, especially in light of the
kloud initiative, but I think that it would help promote Karaf more
aggressively.

Regards,
  Serge...

On Wed, Feb 13, 2019 at 9:06 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Good point Serge.
>
> The huge advantage of Karaf is our "polymorphic" approach: we can
> address lot of different packaging, use cases, etc.
>
> So, update is a key thing as well (more for dynamic approach than static
> I think).
>
> I forgot to mention one area where we would need help: spread the word
> and advertising. With the kloud initiative, I think we can seduce more
> users, but they have to find Karaf and what they can do with it and how
> Karaf can help them.
>
> I created new Jira yesterday evening, and now I'm starting from PoC that
> you will be able to see as PRs soon.
>
> Thanks for your enthusiasm and your interest in Karaf !
>
> Let's build the "new" Karaf ;)
>
> Regards
> JB
>
> On 13/02/2019 08:29, Serge Huber wrote:
> > +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
> > <da...@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

Re: [DISCUSS] Launching the kloud initiative

Posted by Francois Papon <fr...@openobject.fr>.
Hi,

Yes, I'm agree about the "polymorphic" approach, this is really a big
advantage compare to others framework!

Users can using Karaf as dynamic runtime or with Winegrower for the
static approach, according to their environment (on-premise, cloud....).

We have all the features to make the new Karaf awesome :)

François Papon
fpapon@apache.org

Le 13/02/2019 à 12:06, Jean-Baptiste Onofré a écrit :
> Good point Serge.
>
> The huge advantage of Karaf is our "polymorphic" approach: we can
> address lot of different packaging, use cases, etc.
>
> So, update is a key thing as well (more for dynamic approach than static
> I think).
>
> I forgot to mention one area where we would need help: spread the word
> and advertising. With the kloud initiative, I think we can seduce more
> users, but they have to find Karaf and what they can do with it and how
> Karaf can help them.
>
> I created new Jira yesterday evening, and now I'm starting from PoC that
> you will be able to see as PRs soon.
>
> Thanks for your enthusiasm and your interest in Karaf !
>
> Let's build the "new" Karaf ;)
>
> Regards
> JB
>
> On 13/02/2019 08:29, Serge Huber wrote:
>> +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
>> <da...@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
>>>>

Re: [DISCUSS] Launching the kloud initiative

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Good point Serge.

The huge advantage of Karaf is our "polymorphic" approach: we can
address lot of different packaging, use cases, etc.

So, update is a key thing as well (more for dynamic approach than static
I think).

I forgot to mention one area where we would need help: spread the word
and advertising. With the kloud initiative, I think we can seduce more
users, but they have to find Karaf and what they can do with it and how
Karaf can help them.

I created new Jira yesterday evening, and now I'm starting from PoC that
you will be able to see as PRs soon.

Thanks for your enthusiasm and your interest in Karaf !

Let's build the "new" Karaf ;)

Regards
JB

On 13/02/2019 08:29, Serge Huber wrote:
> +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
> <da...@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

Re: [DISCUSS] Launching the kloud initiative

Posted by Serge Huber <sh...@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
<da...@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
> >

Re: [DISCUSS] Launching the kloud initiative

Posted by David Daniel <da...@gmail.com>.
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
>

Re: [DISCUSS] Launching the kloud initiative

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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

Re: [DISCUSS] Launching the kloud initiative

Posted by David Daniel <da...@gmail.com>.
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
>