incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [ASFCS40][DISCUSS] How should we move forward to resolution on the config files in "patches"? Was: "Re: [ASFCS40] Configuration file licensing followup"
Date Tue, 25 Sep 2012 00:35:11 GMT
On Mon, Sep 24, 2012 at 2:53 PM, Chiradeep Vittal
<Chiradeep.Vittal@citrix.com> wrote:
>
>
> On 9/21/12 8:37 PM, "Chip Childers" <chip.childers@sungard.com> wrote:
>
>>On Sep 21, 2012, at 8:59 PM, Chiradeep Vittal
>><Chiradeep.Vittal@citrix.com> wrote:
>>
>>>
>>> I am unable to resolve
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-147.
>>> Perhaps we need a cleanroom implementation or an exception.
>>> CLOUDSTACK-147 is the only one in "Unresolved" state
>>>
>>> Cheers
>>> --
>>> Chiradeep
>>>
>>>
>>>
>>
>>Wow, this is fantastic news!
>>
>>Yes, thee RAT stuff probably needs to be adjusted a bit (which I'll
>>happily own). We also need to do the licensing stuff for the files
>>originally included from other projects (again, I'm more than willing
>>to get that done early next week).
>>
>>For that unresolved issue, perhaps we can try what Joe did for
>>CLOUDSTACK-146?  Does someone want to try and track down the orig
>>developer?  If not, this is a specific item that we can ask for an
>>exception on from the legal folks.
>>
>>-chip
>
> There is no "original developer", it is a delta from the stock Debian
> config.

By "original developer", I meant that we could go to the source
project for the file itself and ask what claims they believe they have
on the file (and / or willingness to change).  Does it make sense to
try that?

>
> I can reduce rsyslog.conf to the following 10-line delta from the stock
> Debian rsyslog.conf
> 16,17c16,17
>
> < #$ModLoad imudp
> < #$UDPServerRun 514
> ---
>> $ModLoad imudp
>> $UDPServerRun 3914
> 57,58c57,58
> < *.*;auth,authpriv.none                -/var/log/syslog
> < #cron.*                               /var/log/cron.log
> ---
>> #*.*;auth,authpriv.none               -/var/log/syslog
>> cron.*                                /var/log/cron.log
> 79a80,81
>>
>> local0.*      -/var/log/haproxy.log
> 83,85c85,87
> < *.=debug;\
> <       auth,authpriv.none;\
> <       news.none;mail.none     -/var/log/debug
> ---
>> #*.=debug;\
>> #     auth,authpriv.none;\
>> #     news.none;mail.none     -/var/log/debug
> 89c91,92
> <       mail,news.none          -/var/log/messages
> ---
>>       local0.none;\
>>       mail.none,news.none             -/var/log/messages
>
>
> I can replace the rsyslog.conf in the source repo with this patch.
> But we need a way to recreate the needed rsyslog.conf from whatever is in
> the system vm at runtime.
>
> Perhaps that is a different bug, one that is a non-blocker for 4.0.
> But a fix would be needed for the next maintenance release or
> whenever a release changes the config files.
>
> Let's say hypothetically that VPN software has a rare bug that
> causes its logging to spin out of control.
> As a stopgap, we release a fix to rsyslog.conf to stop it from logging to
> disk.
> Depending on whether it is a fresh virtual router or an already-patched
> virtual router, the
> patch needed for rsyslog.conf will be different.
>
> --
> Chiradeep
>
>

Mime
View raw message