On 04/17/2012 01:13 PM, Petr Viktorin wrote:
> On 04/17/2012 06:46 PM, John Dennis wrote:
>> Thank you for the explanation Petr, it's very much appreciated.
>> I do have a problem with this patch and I'm inclined to NAK it, but I'm
>> open to discussion. Here's my thoughts, if I've made mistakes in my
>> reasoning please point them out.
>> The fundamental problem is many of our command line utilities do not do
>> logging correctly.
>> Fixing the logging is not terribly difficult but it raises concerns over
>> invasive changes at the last minute.
>> To address the problem we're going to introduce what can only be called
>> a "hack" to compensate for the original deficiency. The hack is a bit
>> obscure and convoluted (and I'm not sure entirely robust). It introduces
>> enough complexity it's not obvious or easy to see what is going on. Code
>> that obscures should be treated with skepticism and be justified by
>> important needs. I'm also afraid what should really be a short term
>> work-around will get ensconced in the code and never cleaned up, it will
>> be duplicated, and used as an example of how things are supposed to
>> So my question is, "Is the output of the command line utilities so
>> broken that it justifies introducing this?" and "Is this any less
>> invasive than simply fixing the messages in the utilities cleanly and
>> not introducing a hack?"
> Yes, it's a hack, because it needs to be non-invasive. It does that by
> not modifying the scripts themselves, but just wrapping them in the
> context handler. So no functionality is broken, there are just
> problems with extra messages printed or not printed. I think that's
> the least invasive thing to do. So the answer to your second question
> is yes. I'm not experienced enough to answer the first one.
> I opened https://fedorahosted.org/freeipa/ticket/2652 to track the
> larger issue that needs solving: removing the code duplication in
> these tools. This includes a common way to configure logging and
> report errors.
Let us do the hack and pick the cleanup task in 3.0 so that we have
things done correctly for future.
If this task is not enough let us open other tasks to make sure that we
track correctly the need to the right fix.
We can even revert the change in 3.0 and go a different path.
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list