Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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  a écrit :
> 
> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  > 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  a écrit
>> :
>>> 
>>> Hello
>>> 
>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
>> 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  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  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 <
>> patriquelega...@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 >>> .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 
>>> 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 pr

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  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  a écrit
> :
> >
> > Hello
> >
> > śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
> 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  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  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 <
>  patriquelega...@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  >> .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 
> > 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 (

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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  a écrit :
> 
> Hello
> 
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre  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  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  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 <
 patriquelega...@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 > .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 
> 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:
>>> 
>>> 
>>> bar
>>> A
>>> B
>>> 
>>> 
>>> The features service will fully install/start bar feature first, then
>>

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

Hello

śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre  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  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  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 <
> >> patriquelega...@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  .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 
> >>> 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:
> >
> > 
> > bar
> > A
> > B
> > 
> >
> > 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.
> >
> >

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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  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  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 <
>> patriquelega...@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 
>>> 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 
>>> 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:
> 
> 
> bar
> A
> B
> 
> 
> 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*
>>> 
>