karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milen Dyankov <milendyan...@gmail.com>
Subject Re: [DISCUSS] Remove features lifecycle in K4
Date Tue, 14 Apr 2015 07:06:09 GMT
Please correct me if I'm wrong but aren't we talking about a problem that
(at least conceptually) has been solved? Package management has been around
in Linux for quite some time. Can't features just mimic the same behavior?
>From my perspective features are quite similar to virtual packages in
Debian based linux distributions.

14 kwi 2015 08:54 "Christian Schneider" <chris@die-schneider.net>

> I was not aware we have this information in the wires. I will try to
> implement it using these.
> So what I would do is this:
> I start with the features to be stopped / started.
> I then propagate down to the subfeatures / bundles.
> For each feature processed I compute the state as the highest state of all
> features that depend on it and the requested state.
> Does that make sense?
> The problem in this algorithm is that in many cases we will not be able to
> stop features / bundles as they are needed by other features.
> So probably we will need some reporting to explain why some features /
> bundles could not achieve the request state. To really stop a feature the
> user would then
> have to stop all top level features. Only then would it really change its
> state.
> We could also have kind of a force mode where we change the state first to
> the top and then down again. So this would guarantee that a feature changes
> its state but it could shut down half of karaf unintendedly. Which would be
> especially dangerous if we hit some core features like the feature service.
> So I tend to rather not support this.
> Christian
> On 13.04.2015 18:01, Guillaume Nodet wrote:
>> Yeah, I was thinking about it.
>> Though the obvious other solution is to fix it.
>> I have actually started an email this morning to discuss but I haven't
>> finished it.
>> Overall, I think it may not be very difficult to fix, as the bundle state
>> changes are already handled correctly afaik.  The real problem is to agree
>> on the semantics on the effects, so that we can compute the desired state
>> of each bundle correctly.
>> Problems arise when a bundle is used by several features, one of which
>> being started and the other resolved.
>> Anyway, it's really up to you, I don't mind fixing the code as long as we
>> agree on the behaviour.
>> 2015-04-13 17:51 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>  Hi all,
>>> I discussed with Christian about KARAF-3102.
>>> The feature lifecycle doesn't actually fully work, especially around the
>>> stop action.
>>> In order to avoid to perturb the users, I think we should remove the
>>> features lifecycle commands. Else, if they are provided, users will try
>>> it
>>> and may be disappointed as they won't work as expected.
>>> WDYT ?
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
> --
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> http://www.talend.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message