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 Onofre <jb...@nanthrax.net> on 2021/05/19 05:35:09 UTC
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Hi,
Regarding recent comments from users and lot of refresh issues/questions we have in the past, I moved forward with a new simple features service that doesn’t use the resolver. It basically reads the features repo definition and just install what’s define in there statically.
I will prepare a distribution using it by default.
I will share some details soon.
Regards
JB
> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a écrit :
>
> Hi,
>
> It doesn’t really break, it just don’t use it.
>
> It’s up to you to install all feature/bundle requirements.
>
> Regards
> JB
>
>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a écrit :
>>
>> Hi,
>>
>>> - ignore requirement/capability (no resolver)
>>
>> did I get it right that this breaks the dependency=true feature that
>> installs bundles / features only if a requirement is not fullfilled yet?
>>
>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>> patriquelegault@gmail.com>:
>>
>>> Same here,
>>>
>>> This is behaviour that has been expected for some time now, reversing it
>>> could cause damage to systems that upgrade to the latest Karaf. I would
>>> make it something that users opt into vs having to opt-out of.
>>>
>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <da...@empirica.io.invalid>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like some kind of backward incompatible change introduced within
>>>> patch version change. I personally would like to keep auto refresh "on"
>>> by
>>>> default as this is expected/desired behavior for me.
>>>>
>>>> Regards
>>>>
>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>> napisał(a):
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We got several user feedback, complaining about unexpected and cascaded
>>>>> (unrelated) refresh while installing features.
>>>>>
>>>>> As reminder, a refresh can happen when:
>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>> package
>>>>> version. In that case, the features service will refresh A to use the
>>>>> newest package version.
>>>>> - bundle A has an optional import to package foo and a bundle provides
>>>>> this package. In that case, the features service will refresh A to
>>>> actually
>>>>> use the import as it’s a "resolved" optional.
>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>> requirement) and B is refreshed. In that case, the features service
>>> will
>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>> instance).
>>>>> This can cause "cascading" refresh.
>>>>>
>>>>> A refresh means that a bundle can be restarted (if the bundle contains
>>> an
>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>
>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>> introduce a new property autoRefresh in
>>> etc/org.apache.karaf.features.cfg
>>>>> to disable the auto refresh by the features service (and let the user
>>>>> decides when he wants to trigger refresh with bundle:refresh command
>>> for
>>>>> instance).
>>>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
>>> on
>>>>> 4.3.x.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>> created a
>>>>> new "simple features service" (PR will be open soon) that:
>>>>>
>>>>> - just take the features definition in order (ignoring start level)
>>>>> - ignore requirement/capability (no resolver)
>>>>> - no auto refresh
>>>>>
>>>>> Basically, if you have the following feature definition:
>>>>>
>>>>> <feature name="foo" version="1.0">
>>>>> <feature>bar</feature>
>>>>> <bundle>A</bundle>
>>>>> <bundle>B</bundle>
>>>>> </feature>
>>>>>
>>>>> The features service will fully install/start bar feature first, then
>>>>> bundle A, then bundle B.
>>>>> To use this "simple features services, you just have to replace
>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>> bundle
>>>>> in etc/startup.properties (or custom distribution).
>>>>>
>>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>> soon,
>>>>> but that’s another thread ;)).
>>>>>
>>>>> The big advantages of this approach is:
>>>>> - predictable/deterministic provisioning (if it works fine, it works
>>>> again)
>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> If you agree, I will move forward on both tasks.
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>>
>>>>
>>>>
>>>> --
>>>> Daniel Łaś
>>>> CTO at Empirica S.A.
>>>> +48 695 616181
>>>>
>>>
>>>
>>> --
>>> *Patrique Legault*
>>>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Same for me ;)
So, let me refactor and remove "my" feature.simple bundle to include in features.core.
I will create the PR soon.
Regards
JB
> Le 19 mai 2021 à 09:21, Grzegorz Grzybek <gr...@gmail.com> a écrit :
>
> śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Yes, both are possible.
>>
>> Maybe keeping all in org.apache.karaf.features.core with a configuration
>> to use a different deploy/approach is better than a complete new features
>> bundle.
>> It’s not a problem to me to refactor what I did.
>>
>> Thoughts ?
>>
>
> Personally I'm 65% for keeping single features.core + configuration option
> and 35% for features.simple ;)
>
> regards
> Grzegorz Grzybek
>
>
>>
>> Regards
>> JB
>>
>>> Le 19 mai 2021 à 08:01, Grzegorz Grzybek <gr...@gmail.com> a écrit
>> :
>>>
>>> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb@nanthrax.net <mailto:
>> jb@nanthrax.net>> napisał(a):
>>>
>>>> Hi,
>>>>
>>>> Actually, it’s a complete separated bundle.
>>>>
>>>> So, in the Karaf standard distribution, you will have
>>>> org.apache.karaf.features.core in etc/startup.properties: that’s the
>>>> regular/current one with the resolver.
>>>>
>>>> Alternatively, you will have another distribution (I have to think about
>>>> the name), where you will have org.apache.karaf.features.simple in
>>>> etc/startup.properties: it doesn’t use the resolver, just loading the
>>>> features model and executing what’s in there.
>>>>
>>>
>>> Another, different, "non-canonical" distribution is fine ;)
>>>
>>>
>>>>
>>>> Another possible approach is a configuration in
>>>> etc/org.apache.karaf.features.cfg where we use a different/pluggable
>>>> deployer.
>>>>
>>>
>>> This can still be done in standard, "canonical" distro, but as
>>> commented-out configuration option.
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>>
>>>
>>>>
>>>> Thoughts ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek <gr...@gmail.com> a
>> écrit
>>>> :
>>>>>
>>>>> Hello
>>>>>
>>>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Regarding recent comments from users and lot of refresh
>> issues/questions
>>>>>> we have in the past, I moved forward with a new simple features
>> service
>>>>>> that doesn’t use the resolver. It basically reads the features repo
>>>>>> definition and just install what’s define in there statically.
>>>>>>
>>>>>> I will prepare a distribution using it by default.
>>>>>>
>>>>>
>>>>> Will it be configurable? I know about refresh problems - but the
>> resolver
>>>>> did a good job showing you what's wrong with the set of
>> features/bundles
>>>>> you're installing.
>>>>> Do you plan to switch to resolverless features service in micro release
>>>> of
>>>>> Karaf? Or will it be Karaf 4.4 / 5?
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>>
>>>>>>
>>>>>> I will share some details soon.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>>>>>> écrit :
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It doesn’t really break, it just don’t use it.
>>>>>>>
>>>>>>> It’s up to you to install all feature/bundle requirements.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
>>>> écrit
>>>>>> :
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>>
>>>>>>>> did I get it right that this breaks the dependency=true feature that
>>>>>>>> installs bundles / features only if a requirement is not fullfilled
>>>> yet?
>>>>>>>>
>>>>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>>>>>> patriquelegault@gmail.com>:
>>>>>>>>
>>>>>>>>> Same here,
>>>>>>>>>
>>>>>>>>> This is behaviour that has been expected for some time now,
>> reversing
>>>>>> it
>>>>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
>>>> would
>>>>>>>>> make it something that users opt into vs having to opt-out of.
>>>>>>>>>
>>>>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
>>>>>> .invalid>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> It looks like some kind of backward incompatible change introduced
>>>>>> within
>>>>>>>>>> patch version change. I personally would like to keep auto refresh
>>>>>> "on"
>>>>>>>>> by
>>>>>>>>>> default as this is expected/desired behavior for me.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>>>> napisał(a):
>>>>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> We got several user feedback, complaining about unexpected and
>>>>>> cascaded
>>>>>>>>>>> (unrelated) refresh while installing features.
>>>>>>>>>>>
>>>>>>>>>>> As reminder, a refresh can happen when:
>>>>>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>>>>>> package
>>>>>>>>>>> version. In that case, the features service will refresh A to use
>>>> the
>>>>>>>>>>> newest package version.
>>>>>>>>>>> - bundle A has an optional import to package foo and a bundle
>>>>>> provides
>>>>>>>>>>> this package. In that case, the features service will refresh A
>> to
>>>>>>>>>> actually
>>>>>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>>>>>> requirement) and B is refreshed. In that case, the features
>> service
>>>>>>>>> will
>>>>>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>>>>>> instance).
>>>>>>>>>>> This can cause "cascading" refresh.
>>>>>>>>>>>
>>>>>>>>>>> A refresh means that a bundle can be restarted (if the bundle
>>>>>> contains
>>>>>>>>> an
>>>>>>>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>>>>>>>
>>>>>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose
>> to
>>>>>>>>>>> introduce a new property autoRefresh in
>>>>>>>>> etc/org.apache.karaf.features.cfg
>>>>>>>>>>> to disable the auto refresh by the features service (and let the
>>>> user
>>>>>>>>>>> decides when he wants to trigger refresh with bundle:refresh
>>>> command
>>>>>>>>> for
>>>>>>>>>>> instance).
>>>>>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
>>>>>> autoRefresh=false
>>>>>>>>> on
>>>>>>>>>>> 4.3.x.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>
>>>>>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>>>>>>>> created a
>>>>>>>>>>> new "simple features service" (PR will be open soon) that:
>>>>>>>>>>>
>>>>>>>>>>> - just take the features definition in order (ignoring start
>> level)
>>>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>>>>> - no auto refresh
>>>>>>>>>>>
>>>>>>>>>>> Basically, if you have the following feature definition:
>>>>>>>>>>>
>>>>>>>>>>> <feature name="foo" version="1.0">
>>>>>>>>>>> <feature>bar</feature>
>>>>>>>>>>> <bundle>A</bundle>
>>>>>>>>>>> <bundle>B</bundle>
>>>>>>>>>>> </feature>
>>>>>>>>>>>
>>>>>>>>>>> The features service will fully install/start bar feature first,
>>>> then
>>>>>>>>>>> bundle A, then bundle B.
>>>>>>>>>>> To use this "simple features services, you just have to replace
>>>>>>>>>>> org.apache.karaf.features.core by
>> org.apache.karaf.features.simple
>>>>>>>>> bundle
>>>>>>>>>>> in etc/startup.properties (or custom distribution).
>>>>>>>>>>>
>>>>>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
>>>> complete
>>>>>>>>>>> details about Karaf 5 and its concepts (module, extension, …)
>> very
>>>>>>>>> soon,
>>>>>>>>>>> but that’s another thread ;)).
>>>>>>>>>>>
>>>>>>>>>>> The big advantages of this approach is:
>>>>>>>>>>> - predictable/deterministic provisioning (if it works fine, it
>>>> works
>>>>>>>>>> again)
>>>>>>>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>>>>>>>
>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>
>>>>>>>>>>> If you agree, I will move forward on both tasks.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Daniel Łaś
>>>>>>>>>> CTO at Empirica S.A.
>>>>>>>>>> +48 695 616181
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Patrique Legault*
>>
>>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Yes, both are possible.
>
> Maybe keeping all in org.apache.karaf.features.core with a configuration
> to use a different deploy/approach is better than a complete new features
> bundle.
> It’s not a problem to me to refactor what I did.
>
> Thoughts ?
>
Personally I'm 65% for keeping single features.core + configuration option
and 35% for features.simple ;)
regards
Grzegorz Grzybek
>
> Regards
> JB
>
> > Le 19 mai 2021 à 08:01, Grzegorz Grzybek <gr...@gmail.com> a écrit
> :
> >
> > śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb@nanthrax.net <mailto:
> jb@nanthrax.net>> napisał(a):
> >
> >> Hi,
> >>
> >> Actually, it’s a complete separated bundle.
> >>
> >> So, in the Karaf standard distribution, you will have
> >> org.apache.karaf.features.core in etc/startup.properties: that’s the
> >> regular/current one with the resolver.
> >>
> >> Alternatively, you will have another distribution (I have to think about
> >> the name), where you will have org.apache.karaf.features.simple in
> >> etc/startup.properties: it doesn’t use the resolver, just loading the
> >> features model and executing what’s in there.
> >>
> >
> > Another, different, "non-canonical" distribution is fine ;)
> >
> >
> >>
> >> Another possible approach is a configuration in
> >> etc/org.apache.karaf.features.cfg where we use a different/pluggable
> >> deployer.
> >>
> >
> > This can still be done in standard, "canonical" distro, but as
> > commented-out configuration option.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
> >>
> >>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek <gr...@gmail.com> a
> écrit
> >> :
> >>>
> >>> Hello
> >>>
> >>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi,
> >>>>
> >>>> Regarding recent comments from users and lot of refresh
> issues/questions
> >>>> we have in the past, I moved forward with a new simple features
> service
> >>>> that doesn’t use the resolver. It basically reads the features repo
> >>>> definition and just install what’s define in there statically.
> >>>>
> >>>> I will prepare a distribution using it by default.
> >>>>
> >>>
> >>> Will it be configurable? I know about refresh problems - but the
> resolver
> >>> did a good job showing you what's wrong with the set of
> features/bundles
> >>> you're installing.
> >>> Do you plan to switch to resolverless features service in micro release
> >> of
> >>> Karaf? Or will it be Karaf 4.4 / 5?
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>>
> >>>>
> >>>> I will share some details soon.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> >>>> écrit :
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> It doesn’t really break, it just don’t use it.
> >>>>>
> >>>>> It’s up to you to install all feature/bundle requirements.
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
> >> écrit
> >>>> :
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> - ignore requirement/capability (no resolver)
> >>>>>>
> >>>>>> did I get it right that this breaks the dependency=true feature that
> >>>>>> installs bundles / features only if a requirement is not fullfilled
> >> yet?
> >>>>>>
> >>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >>>>>> patriquelegault@gmail.com>:
> >>>>>>
> >>>>>>> Same here,
> >>>>>>>
> >>>>>>> This is behaviour that has been expected for some time now,
> reversing
> >>>> it
> >>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
> >> would
> >>>>>>> make it something that users opt into vs having to opt-out of.
> >>>>>>>
> >>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
> >>>> .invalid>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> It looks like some kind of backward incompatible change introduced
> >>>> within
> >>>>>>>> patch version change. I personally would like to keep auto refresh
> >>>> "on"
> >>>>>>> by
> >>>>>>>> default as this is expected/desired behavior for me.
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>>
> >>>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>>>>>> napisał(a):
> >>>>>>>>
> >>>>>>>>> Hi everyone,
> >>>>>>>>>
> >>>>>>>>> We got several user feedback, complaining about unexpected and
> >>>> cascaded
> >>>>>>>>> (unrelated) refresh while installing features.
> >>>>>>>>>
> >>>>>>>>> As reminder, a refresh can happen when:
> >>>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
> >>>>>>> package
> >>>>>>>>> version. In that case, the features service will refresh A to use
> >> the
> >>>>>>>>> newest package version.
> >>>>>>>>> - bundle A has an optional import to package foo and a bundle
> >>>> provides
> >>>>>>>>> this package. In that case, the features service will refresh A
> to
> >>>>>>>> actually
> >>>>>>>>> use the import as it’s a "resolved" optional.
> >>>>>>>>> - bundle A is wired to bundle B (from a package perspective or
> >>>>>>>>> requirement) and B is refreshed. In that case, the features
> service
> >>>>>>> will
> >>>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
> >>>>>>>> instance).
> >>>>>>>>> This can cause "cascading" refresh.
> >>>>>>>>>
> >>>>>>>>> A refresh means that a bundle can be restarted (if the bundle
> >>>> contains
> >>>>>>> an
> >>>>>>>>> activator or similar (DS component, blueprint bundle)).
> >>>>>>>>>
> >>>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose
> to
> >>>>>>>>> introduce a new property autoRefresh in
> >>>>>>> etc/org.apache.karaf.features.cfg
> >>>>>>>>> to disable the auto refresh by the features service (and let the
> >> user
> >>>>>>>>> decides when he wants to trigger refresh with bundle:refresh
> >> command
> >>>>>>> for
> >>>>>>>>> instance).
> >>>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
> >>>> autoRefresh=false
> >>>>>>> on
> >>>>>>>>> 4.3.x.
> >>>>>>>>>
> >>>>>>>>> Thoughts ?
> >>>>>>>>>
> >>>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
> >>>>>>> created a
> >>>>>>>>> new "simple features service" (PR will be open soon) that:
> >>>>>>>>>
> >>>>>>>>> - just take the features definition in order (ignoring start
> level)
> >>>>>>>>> - ignore requirement/capability (no resolver)
> >>>>>>>>> - no auto refresh
> >>>>>>>>>
> >>>>>>>>> Basically, if you have the following feature definition:
> >>>>>>>>>
> >>>>>>>>> <feature name="foo" version="1.0">
> >>>>>>>>> <feature>bar</feature>
> >>>>>>>>> <bundle>A</bundle>
> >>>>>>>>> <bundle>B</bundle>
> >>>>>>>>> </feature>
> >>>>>>>>>
> >>>>>>>>> The features service will fully install/start bar feature first,
> >> then
> >>>>>>>>> bundle A, then bundle B.
> >>>>>>>>> To use this "simple features services, you just have to replace
> >>>>>>>>> org.apache.karaf.features.core by
> org.apache.karaf.features.simple
> >>>>>>> bundle
> >>>>>>>>> in etc/startup.properties (or custom distribution).
> >>>>>>>>>
> >>>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
> >> complete
> >>>>>>>>> details about Karaf 5 and its concepts (module, extension, …)
> very
> >>>>>>> soon,
> >>>>>>>>> but that’s another thread ;)).
> >>>>>>>>>
> >>>>>>>>> The big advantages of this approach is:
> >>>>>>>>> - predictable/deterministic provisioning (if it works fine, it
> >> works
> >>>>>>>> again)
> >>>>>>>>> - faster deployment (I estimated the gain to about 70%)
> >>>>>>>>>
> >>>>>>>>> Thoughts ?
> >>>>>>>>>
> >>>>>>>>> If you agree, I will move forward on both tasks.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Regards
> >>>>>>>>> JB
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Daniel Łaś
> >>>>>>>> CTO at Empirica S.A.
> >>>>>>>> +48 695 616181
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> *Patrique Legault*
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Yes, both are possible.
Maybe keeping all in org.apache.karaf.features.core with a configuration to use a different deploy/approach is better than a complete new features bundle.
It’s not a problem to me to refactor what I did.
Thoughts ?
Regards
JB
> Le 19 mai 2021 à 08:01, Grzegorz Grzybek <gr...@gmail.com> a écrit :
>
> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
>
>> Hi,
>>
>> Actually, it’s a complete separated bundle.
>>
>> So, in the Karaf standard distribution, you will have
>> org.apache.karaf.features.core in etc/startup.properties: that’s the
>> regular/current one with the resolver.
>>
>> Alternatively, you will have another distribution (I have to think about
>> the name), where you will have org.apache.karaf.features.simple in
>> etc/startup.properties: it doesn’t use the resolver, just loading the
>> features model and executing what’s in there.
>>
>
> Another, different, "non-canonical" distribution is fine ;)
>
>
>>
>> Another possible approach is a configuration in
>> etc/org.apache.karaf.features.cfg where we use a different/pluggable
>> deployer.
>>
>
> This can still be done in standard, "canonical" distro, but as
> commented-out configuration option.
>
> regards
> Grzegorz Grzybek
>
>
>
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek <gr...@gmail.com> a écrit
>> :
>>>
>>> Hello
>>>
>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi,
>>>>
>>>> Regarding recent comments from users and lot of refresh issues/questions
>>>> we have in the past, I moved forward with a new simple features service
>>>> that doesn’t use the resolver. It basically reads the features repo
>>>> definition and just install what’s define in there statically.
>>>>
>>>> I will prepare a distribution using it by default.
>>>>
>>>
>>> Will it be configurable? I know about refresh problems - but the resolver
>>> did a good job showing you what's wrong with the set of features/bundles
>>> you're installing.
>>> Do you plan to switch to resolverless features service in micro release
>> of
>>> Karaf? Or will it be Karaf 4.4 / 5?
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>>
>>>>
>>>> I will share some details soon.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>>>> écrit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> It doesn’t really break, it just don’t use it.
>>>>>
>>>>> It’s up to you to install all feature/bundle requirements.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
>> écrit
>>>> :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>
>>>>>> did I get it right that this breaks the dependency=true feature that
>>>>>> installs bundles / features only if a requirement is not fullfilled
>> yet?
>>>>>>
>>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>>>> patriquelegault@gmail.com>:
>>>>>>
>>>>>>> Same here,
>>>>>>>
>>>>>>> This is behaviour that has been expected for some time now, reversing
>>>> it
>>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
>> would
>>>>>>> make it something that users opt into vs having to opt-out of.
>>>>>>>
>>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
>>>> .invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It looks like some kind of backward incompatible change introduced
>>>> within
>>>>>>>> patch version change. I personally would like to keep auto refresh
>>>> "on"
>>>>>>> by
>>>>>>>> default as this is expected/desired behavior for me.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>> napisał(a):
>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> We got several user feedback, complaining about unexpected and
>>>> cascaded
>>>>>>>>> (unrelated) refresh while installing features.
>>>>>>>>>
>>>>>>>>> As reminder, a refresh can happen when:
>>>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>>>> package
>>>>>>>>> version. In that case, the features service will refresh A to use
>> the
>>>>>>>>> newest package version.
>>>>>>>>> - bundle A has an optional import to package foo and a bundle
>>>> provides
>>>>>>>>> this package. In that case, the features service will refresh A to
>>>>>>>> actually
>>>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>>>> requirement) and B is refreshed. In that case, the features service
>>>>>>> will
>>>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>>>> instance).
>>>>>>>>> This can cause "cascading" refresh.
>>>>>>>>>
>>>>>>>>> A refresh means that a bundle can be restarted (if the bundle
>>>> contains
>>>>>>> an
>>>>>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>>>>>
>>>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>>>>>> introduce a new property autoRefresh in
>>>>>>> etc/org.apache.karaf.features.cfg
>>>>>>>>> to disable the auto refresh by the features service (and let the
>> user
>>>>>>>>> decides when he wants to trigger refresh with bundle:refresh
>> command
>>>>>>> for
>>>>>>>>> instance).
>>>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
>>>> autoRefresh=false
>>>>>>> on
>>>>>>>>> 4.3.x.
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>>
>>>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>>>>>> created a
>>>>>>>>> new "simple features service" (PR will be open soon) that:
>>>>>>>>>
>>>>>>>>> - just take the features definition in order (ignoring start level)
>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>>> - no auto refresh
>>>>>>>>>
>>>>>>>>> Basically, if you have the following feature definition:
>>>>>>>>>
>>>>>>>>> <feature name="foo" version="1.0">
>>>>>>>>> <feature>bar</feature>
>>>>>>>>> <bundle>A</bundle>
>>>>>>>>> <bundle>B</bundle>
>>>>>>>>> </feature>
>>>>>>>>>
>>>>>>>>> The features service will fully install/start bar feature first,
>> then
>>>>>>>>> bundle A, then bundle B.
>>>>>>>>> To use this "simple features services, you just have to replace
>>>>>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>>>>>> bundle
>>>>>>>>> in etc/startup.properties (or custom distribution).
>>>>>>>>>
>>>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
>> complete
>>>>>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>>>>>> soon,
>>>>>>>>> but that’s another thread ;)).
>>>>>>>>>
>>>>>>>>> The big advantages of this approach is:
>>>>>>>>> - predictable/deterministic provisioning (if it works fine, it
>> works
>>>>>>>> again)
>>>>>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>>
>>>>>>>>> If you agree, I will move forward on both tasks.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel Łaś
>>>>>>>> CTO at Empirica S.A.
>>>>>>>> +48 695 616181
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Patrique Legault*
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi,
>
> Actually, it’s a complete separated bundle.
>
> So, in the Karaf standard distribution, you will have
> org.apache.karaf.features.core in etc/startup.properties: that’s the
> regular/current one with the resolver.
>
> Alternatively, you will have another distribution (I have to think about
> the name), where you will have org.apache.karaf.features.simple in
> etc/startup.properties: it doesn’t use the resolver, just loading the
> features model and executing what’s in there.
>
Another, different, "non-canonical" distribution is fine ;)
>
> Another possible approach is a configuration in
> etc/org.apache.karaf.features.cfg where we use a different/pluggable
> deployer.
>
This can still be done in standard, "canonical" distro, but as
commented-out configuration option.
regards
Grzegorz Grzybek
>
> Thoughts ?
>
> Regards
> JB
>
> > Le 19 mai 2021 à 07:41, Grzegorz Grzybek <gr...@gmail.com> a écrit
> :
> >
> > Hello
> >
> > śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi,
> >>
> >> Regarding recent comments from users and lot of refresh issues/questions
> >> we have in the past, I moved forward with a new simple features service
> >> that doesn’t use the resolver. It basically reads the features repo
> >> definition and just install what’s define in there statically.
> >>
> >> I will prepare a distribution using it by default.
> >>
> >
> > Will it be configurable? I know about refresh problems - but the resolver
> > did a good job showing you what's wrong with the set of features/bundles
> > you're installing.
> > Do you plan to switch to resolverless features service in micro release
> of
> > Karaf? Or will it be Karaf 4.4 / 5?
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >>
> >> I will share some details soon.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> >> écrit :
> >>>
> >>> Hi,
> >>>
> >>> It doesn’t really break, it just don’t use it.
> >>>
> >>> It’s up to you to install all feature/bundle requirements.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
> écrit
> >> :
> >>>>
> >>>> Hi,
> >>>>
> >>>>> - ignore requirement/capability (no resolver)
> >>>>
> >>>> did I get it right that this breaks the dependency=true feature that
> >>>> installs bundles / features only if a requirement is not fullfilled
> yet?
> >>>>
> >>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >>>> patriquelegault@gmail.com>:
> >>>>
> >>>>> Same here,
> >>>>>
> >>>>> This is behaviour that has been expected for some time now, reversing
> >> it
> >>>>> could cause damage to systems that upgrade to the latest Karaf. I
> would
> >>>>> make it something that users opt into vs having to opt-out of.
> >>>>>
> >>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
> >> .invalid>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> It looks like some kind of backward incompatible change introduced
> >> within
> >>>>>> patch version change. I personally would like to keep auto refresh
> >> "on"
> >>>>> by
> >>>>>> default as this is expected/desired behavior for me.
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>>>> napisał(a):
> >>>>>>
> >>>>>>> Hi everyone,
> >>>>>>>
> >>>>>>> We got several user feedback, complaining about unexpected and
> >> cascaded
> >>>>>>> (unrelated) refresh while installing features.
> >>>>>>>
> >>>>>>> As reminder, a refresh can happen when:
> >>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
> >>>>> package
> >>>>>>> version. In that case, the features service will refresh A to use
> the
> >>>>>>> newest package version.
> >>>>>>> - bundle A has an optional import to package foo and a bundle
> >> provides
> >>>>>>> this package. In that case, the features service will refresh A to
> >>>>>> actually
> >>>>>>> use the import as it’s a "resolved" optional.
> >>>>>>> - bundle A is wired to bundle B (from a package perspective or
> >>>>>>> requirement) and B is refreshed. In that case, the features service
> >>>>> will
> >>>>>>> refresh A as B is itself refreshed (for the previous reasons for
> >>>>>> instance).
> >>>>>>> This can cause "cascading" refresh.
> >>>>>>>
> >>>>>>> A refresh means that a bundle can be restarted (if the bundle
> >> contains
> >>>>> an
> >>>>>>> activator or similar (DS component, blueprint bundle)).
> >>>>>>>
> >>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> >>>>>>> introduce a new property autoRefresh in
> >>>>> etc/org.apache.karaf.features.cfg
> >>>>>>> to disable the auto refresh by the features service (and let the
> user
> >>>>>>> decides when he wants to trigger refresh with bundle:refresh
> command
> >>>>> for
> >>>>>>> instance).
> >>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
> >> autoRefresh=false
> >>>>> on
> >>>>>>> 4.3.x.
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
> >>>>> created a
> >>>>>>> new "simple features service" (PR will be open soon) that:
> >>>>>>>
> >>>>>>> - just take the features definition in order (ignoring start level)
> >>>>>>> - ignore requirement/capability (no resolver)
> >>>>>>> - no auto refresh
> >>>>>>>
> >>>>>>> Basically, if you have the following feature definition:
> >>>>>>>
> >>>>>>> <feature name="foo" version="1.0">
> >>>>>>> <feature>bar</feature>
> >>>>>>> <bundle>A</bundle>
> >>>>>>> <bundle>B</bundle>
> >>>>>>> </feature>
> >>>>>>>
> >>>>>>> The features service will fully install/start bar feature first,
> then
> >>>>>>> bundle A, then bundle B.
> >>>>>>> To use this "simple features services, you just have to replace
> >>>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
> >>>>> bundle
> >>>>>>> in etc/startup.properties (or custom distribution).
> >>>>>>>
> >>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
> complete
> >>>>>>> details about Karaf 5 and its concepts (module, extension, …) very
> >>>>> soon,
> >>>>>>> but that’s another thread ;)).
> >>>>>>>
> >>>>>>> The big advantages of this approach is:
> >>>>>>> - predictable/deterministic provisioning (if it works fine, it
> works
> >>>>>> again)
> >>>>>>> - faster deployment (I estimated the gain to about 70%)
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> If you agree, I will move forward on both tasks.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daniel Łaś
> >>>>>> CTO at Empirica S.A.
> >>>>>> +48 695 616181
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *Patrique Legault*
> >>>>>
> >>>
> >>
> >>
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi,
Actually, it’s a complete separated bundle.
So, in the Karaf standard distribution, you will have org.apache.karaf.features.core in etc/startup.properties: that’s the regular/current one with the resolver.
Alternatively, you will have another distribution (I have to think about the name), where you will have org.apache.karaf.features.simple in etc/startup.properties: it doesn’t use the resolver, just loading the features model and executing what’s in there.
Another possible approach is a configuration in etc/org.apache.karaf.features.cfg where we use a different/pluggable deployer.
Thoughts ?
Regards
JB
> Le 19 mai 2021 à 07:41, Grzegorz Grzybek <gr...@gmail.com> a écrit :
>
> Hello
>
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi,
>>
>> Regarding recent comments from users and lot of refresh issues/questions
>> we have in the past, I moved forward with a new simple features service
>> that doesn’t use the resolver. It basically reads the features repo
>> definition and just install what’s define in there statically.
>>
>> I will prepare a distribution using it by default.
>>
>
> Will it be configurable? I know about refresh problems - but the resolver
> did a good job showing you what's wrong with the set of features/bundles
> you're installing.
> Do you plan to switch to resolverless features service in micro release of
> Karaf? Or will it be Karaf 4.4 / 5?
>
> regards
> Grzegorz Grzybek
>
>
>>
>> I will share some details soon.
>>
>> Regards
>> JB
>>
>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>> écrit :
>>>
>>> Hi,
>>>
>>> It doesn’t really break, it just don’t use it.
>>>
>>> It’s up to you to install all feature/bundle requirements.
>>>
>>> Regards
>>> JB
>>>
>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a écrit
>> :
>>>>
>>>> Hi,
>>>>
>>>>> - ignore requirement/capability (no resolver)
>>>>
>>>> did I get it right that this breaks the dependency=true feature that
>>>> installs bundles / features only if a requirement is not fullfilled yet?
>>>>
>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>> patriquelegault@gmail.com>:
>>>>
>>>>> Same here,
>>>>>
>>>>> This is behaviour that has been expected for some time now, reversing
>> it
>>>>> could cause damage to systems that upgrade to the latest Karaf. I would
>>>>> make it something that users opt into vs having to opt-out of.
>>>>>
>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
>> .invalid>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It looks like some kind of backward incompatible change introduced
>> within
>>>>>> patch version change. I personally would like to keep auto refresh
>> "on"
>>>>> by
>>>>>> default as this is expected/desired behavior for me.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>> napisał(a):
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> We got several user feedback, complaining about unexpected and
>> cascaded
>>>>>>> (unrelated) refresh while installing features.
>>>>>>>
>>>>>>> As reminder, a refresh can happen when:
>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>> package
>>>>>>> version. In that case, the features service will refresh A to use the
>>>>>>> newest package version.
>>>>>>> - bundle A has an optional import to package foo and a bundle
>> provides
>>>>>>> this package. In that case, the features service will refresh A to
>>>>>> actually
>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>> requirement) and B is refreshed. In that case, the features service
>>>>> will
>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>> instance).
>>>>>>> This can cause "cascading" refresh.
>>>>>>>
>>>>>>> A refresh means that a bundle can be restarted (if the bundle
>> contains
>>>>> an
>>>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>>>
>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>>>> introduce a new property autoRefresh in
>>>>> etc/org.apache.karaf.features.cfg
>>>>>>> to disable the auto refresh by the features service (and let the user
>>>>>>> decides when he wants to trigger refresh with bundle:refresh command
>>>>> for
>>>>>>> instance).
>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
>> autoRefresh=false
>>>>> on
>>>>>>> 4.3.x.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>>>> created a
>>>>>>> new "simple features service" (PR will be open soon) that:
>>>>>>>
>>>>>>> - just take the features definition in order (ignoring start level)
>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>> - no auto refresh
>>>>>>>
>>>>>>> Basically, if you have the following feature definition:
>>>>>>>
>>>>>>> <feature name="foo" version="1.0">
>>>>>>> <feature>bar</feature>
>>>>>>> <bundle>A</bundle>
>>>>>>> <bundle>B</bundle>
>>>>>>> </feature>
>>>>>>>
>>>>>>> The features service will fully install/start bar feature first, then
>>>>>>> bundle A, then bundle B.
>>>>>>> To use this "simple features services, you just have to replace
>>>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>>>> bundle
>>>>>>> in etc/startup.properties (or custom distribution).
>>>>>>>
>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>>>> soon,
>>>>>>> but that’s another thread ;)).
>>>>>>>
>>>>>>> The big advantages of this approach is:
>>>>>>> - predictable/deterministic provisioning (if it works fine, it works
>>>>>> again)
>>>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> If you agree, I will move forward on both tasks.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daniel Łaś
>>>>>> CTO at Empirica S.A.
>>>>>> +48 695 616181
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Patrique Legault*
>>>>>
>>>
>>
>>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi,
>
> Regarding recent comments from users and lot of refresh issues/questions
> we have in the past, I moved forward with a new simple features service
> that doesn’t use the resolver. It basically reads the features repo
> definition and just install what’s define in there statically.
>
> I will prepare a distribution using it by default.
>
Will it be configurable? I know about refresh problems - but the resolver
did a good job showing you what's wrong with the set of features/bundles
you're installing.
Do you plan to switch to resolverless features service in micro release of
Karaf? Or will it be Karaf 4.4 / 5?
regards
Grzegorz Grzybek
>
> I will share some details soon.
>
> Regards
> JB
>
> > Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> écrit :
> >
> > Hi,
> >
> > It doesn’t really break, it just don’t use it.
> >
> > It’s up to you to install all feature/bundle requirements.
> >
> > Regards
> > JB
> >
> >> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a écrit
> :
> >>
> >> Hi,
> >>
> >>> - ignore requirement/capability (no resolver)
> >>
> >> did I get it right that this breaks the dependency=true feature that
> >> installs bundles / features only if a requirement is not fullfilled yet?
> >>
> >> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >> patriquelegault@gmail.com>:
> >>
> >>> Same here,
> >>>
> >>> This is behaviour that has been expected for some time now, reversing
> it
> >>> could cause damage to systems that upgrade to the latest Karaf. I would
> >>> make it something that users opt into vs having to opt-out of.
> >>>
> >>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
> .invalid>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> It looks like some kind of backward incompatible change introduced
> within
> >>>> patch version change. I personally would like to keep auto refresh
> "on"
> >>> by
> >>>> default as this is expected/desired behavior for me.
> >>>>
> >>>> Regards
> >>>>
> >>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>> napisał(a):
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> We got several user feedback, complaining about unexpected and
> cascaded
> >>>>> (unrelated) refresh while installing features.
> >>>>>
> >>>>> As reminder, a refresh can happen when:
> >>>>> - bundle A imports package foo:1 and a bundle provides newer foo
> >>> package
> >>>>> version. In that case, the features service will refresh A to use the
> >>>>> newest package version.
> >>>>> - bundle A has an optional import to package foo and a bundle
> provides
> >>>>> this package. In that case, the features service will refresh A to
> >>>> actually
> >>>>> use the import as it’s a "resolved" optional.
> >>>>> - bundle A is wired to bundle B (from a package perspective or
> >>>>> requirement) and B is refreshed. In that case, the features service
> >>> will
> >>>>> refresh A as B is itself refreshed (for the previous reasons for
> >>>> instance).
> >>>>> This can cause "cascading" refresh.
> >>>>>
> >>>>> A refresh means that a bundle can be restarted (if the bundle
> contains
> >>> an
> >>>>> activator or similar (DS component, blueprint bundle)).
> >>>>>
> >>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> >>>>> introduce a new property autoRefresh in
> >>> etc/org.apache.karaf.features.cfg
> >>>>> to disable the auto refresh by the features service (and let the user
> >>>>> decides when he wants to trigger refresh with bundle:refresh command
> >>> for
> >>>>> instance).
> >>>>> I propose to keep autoRefresh=true on 4.2.x and turn
> autoRefresh=false
> >>> on
> >>>>> 4.3.x.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> On the other hand (and to prepare the "path" to Karaf5), I have
> >>> created a
> >>>>> new "simple features service" (PR will be open soon) that:
> >>>>>
> >>>>> - just take the features definition in order (ignoring start level)
> >>>>> - ignore requirement/capability (no resolver)
> >>>>> - no auto refresh
> >>>>>
> >>>>> Basically, if you have the following feature definition:
> >>>>>
> >>>>> <feature name="foo" version="1.0">
> >>>>> <feature>bar</feature>
> >>>>> <bundle>A</bundle>
> >>>>> <bundle>B</bundle>
> >>>>> </feature>
> >>>>>
> >>>>> The features service will fully install/start bar feature first, then
> >>>>> bundle A, then bundle B.
> >>>>> To use this "simple features services, you just have to replace
> >>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
> >>> bundle
> >>>>> in etc/startup.properties (or custom distribution).
> >>>>>
> >>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
> >>>>> details about Karaf 5 and its concepts (module, extension, …) very
> >>> soon,
> >>>>> but that’s another thread ;)).
> >>>>>
> >>>>> The big advantages of this approach is:
> >>>>> - predictable/deterministic provisioning (if it works fine, it works
> >>>> again)
> >>>>> - faster deployment (I estimated the gain to about 70%)
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> If you agree, I will move forward on both tasks.
> >>>>>
> >>>>> Thanks,
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Daniel Łaś
> >>>> CTO at Empirica S.A.
> >>>> +48 695 616181
> >>>>
> >>>
> >>>
> >>> --
> >>> *Patrique Legault*
> >>>
> >
>
>