karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Idea: Allow users to patch feature files
Date Thu, 28 Feb 2013 09:03:29 GMT
Exactly. I think the mapping is ideal for hotfix scenarios where you 
find a problem late and need to solve it in production.
In this case you do not have time for long release processes.

Especially when a bug is in a low level library it can easily lead to 
the following release deps:

- release aries module
- update and release cxf
- update and release camel

This process will take at least about two weeks. In practice I would 
expect at least a month.

With the mapping you can either wait for the aries release and then do 
the mapping or do the patch release in house and do the mapping.

This will make the time to production go down from a month to a few 
hours to days.

As the mapping is separate from the artifacts it is easy to document and 
revert. We only have to deliver some debugging tools that show where the 
mapping
affects artifacts. Then I think this is absolutely manageable and of 
course no admin has to use the mapping. It is just an additional tool 
that can help in some cases.

Christian


On 27.02.2013 23:01, Daniel Kulp wrote:
> After sitting through a series of security related talks this morning and then some chats
with folks at lunch, there is another important use case for the mapping:
>
> Lets pretend a very major security bug or performance issue or similar is found (and
made public) in a particular version of a library.   There is a newer patch version of that
bundle available that fixes that particular issue.   We need to make sure that the old version
is NEVER loaded into the container.  Whenever encountered, we need to make sure all references
to that old version are automatically mapped to the new version.   Without some sort of URL
mapping, how could that be accomplished?  (No OBR here)
>
> As a concrete example of this:  Woodstox 4.1.3 has a severe performance issue in it.
 However, a bunch of features files did reference it as it was the latest for a while.  I'd
like some way to say "don't ever load 4.1.3, always replace it with 4.1.4".  I don't consider
editing anything in system a valid solution.
>
> Thoughts?
>
> Dan
>
>
> On Feb 27, 2013, at 12:56 PM, Achim Nierbeck <bcanhome@googlemail.com> wrote:
>
>> I second Andreas and Guillaume here,
>> this is going to open the gates to Hell and I'm sure I don't want to go
>> that road :)
>>
>> The idea of creating a small set of tools to improve this sounds much more
>> reasonable.
>> And as Filippo already said, how do you want to make sure you have a
>> valid artifact deployed in operations if someone mis-uses this, who has
>> been in
>> charge of breaking the operational system?
>>
>> regards, Achim
>>
>>
>> 2013/2/27 Andreas Pieber <anpieber@gmail.com>
>>
>>> I have to admit one thing: all of those ideas (as summed up nicely by
>>> Ioannis) sound VERY tempting. They would solve some of the problems we're
>>> facing in production and would definitely help many people.
>>>
>>> BUT I'm definitely with Guillaume. This feels like we're opening the gates
>>> to Hell introducing a LOT of possible problems which are anything than
>>> intuitive!
>>>
>>> Wouldn't it be easier providing the tooling providing the correct
>>> features.xml files manually? For example I could think of something like
>>> the mapping features but only for "compile time use" instead of runtime
>>> use. E.g. extending our Karaf Plugin to supporting the url mapping. This
>>> could produce the patched feature files with their own versions in quite a
>>> minimalistic style. Maybe we could even pack this into a simple command
>>> line tool also allowing end users to do this step before starting Karaf.
>>> Finally it's all about fixing problems devs introduce because they weren't
>>> thinking (or lacking the knowledge) while creating the feature files.
>>>
>>> Does this sound completely off the road? Would this make sense?
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>
>>> On Tue, Feb 26, 2013 at 10:24 PM, Guillaume Nodet <gnodet@gmail.com>
>>> wrote:
>>>
>>>> While I don't have any problem at introducing a kind of mapping, I do
>>> fear
>>>> the abuses it can lead to.
>>>> I don't really want to add a feature to be able to fix broken things.
>>>> Valid use cases, sure, broken features descriptors, no.
>>>> So what I mean is that if we allow any kind of global mapping, we can
>>>> easily end up screwing the features even more, i.e. if I override the
>>>> spring stuff as mentionned below, i won't be able to deploy any feature
>>>> that does need the 2.x release of spring (because of version ranges on
>>> the
>>>> packages such as [2.5,3) for example).
>>>>
>>>>
>>>> On Tue, Feb 26, 2013 at 10:05 PM, Ioannis Canellos <iocanel@gmail.com
>>>>> wrote:
>>>>> Some of the views expressed so far:
>>>>>
>>>>> i) Allow defining an alternate location for a feature repository.
>>>>> ii) Allow overriding a feature repository or bundle url using a
>>> mapping.
>>>>> iii) Using version feature version ranges to resolve the right version
>>> to
>>>>> use.
>>>>>
>>>>> Some thoughts about each idea.
>>>>>
>>>>> i) I'd love to be able to do that, even though in most cases modifying
>>>> the
>>>>> feature repo in the system directory does work for me.
>>>>> We could take this one step further an be able to modify the feature
>>> repo
>>>>> itself, using the editor we have in trunk (mostly as a dev tool).
>>>>>
>>>>> ii) I like this idea too. This would solve the recent problem we had
>>> with
>>>>> spring versions. We could just let the user define a mapping like
>>>>> mvn:org.springframework/*/[3,4] =
>>> mvn:org.springframework/*/3.1.2.RELEASE
>>>>> and it would be awesome.
>>>>>
>>>>> iii) This would definetely solve a lot of problems, without direct user
>>>>> interaction. I think that we should maybe start with this point but
>>> maybe
>>>>> also grant the user the power to do things like i) and ii).
>>>>>
>>>>> I hope I didn't miss anything.
>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> *
>>>>>
>>>>> **
>>>>> Blog: http://iocanel.blogspot.com
>>>>> **
>>>>> Twitter: iocanel
>>>>> *
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>
>>
>> -- 
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>> Commiter & Project Lead
>> blog <http://notizblog.nierbeck.de/>


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

Open Source Architect
http://www.talend.com


Mime
View raw message