On 14.03.2016 14:15, Jan Cholasta wrote:
On 14.3.2016 13:56, Rob Crittenden wrote:
Jan Cholasta wrote:
On 11.3.2016 15:56, Gabe Alford wrote:
On Fri, Mar 11, 2016 at 7:35 AM, Petr Vobornik <pvobo...@redhat.com
<mailto:pvobo...@redhat.com>> wrote:

     On 03/11/2016 03:00 PM, Rob Crittenden wrote:

         Martin Kosek wrote:

             On 03/11/2016 09:55 AM, Jan Cholasta wrote:

                 On 11.3.2016 09:33, Martin Kosek wrote:

                     On 03/08/2016 07:07 PM, Martin Basti wrote:



                         On 08.03.2016 16:37, Martin Basti wrote:



                             On 08.03.2016 16:31, Martin Basti wrote:


https://fedorahosted.org/freeipa/ticket/4501

                                 Patch attached.


                             Rebased patch attached.



                         self-NACK

                         Scripts print to CLI unformatted strings, it
                         should not be so easy.
See /var/log/ipaupgrade-{timestamp}.log for more
                         information


                     second-NACK. We cannot break existing log file
                     paths. The paths are mentioned
in a documentation and there may be also automation
                     around that (gathering log
files). So there should be always symlink from the
                     well known location to the
                     newest timestampe'd log.


                 Sorry, but this is absurd. What's the point of
                 maintaining backward
                 compatibility with obsolete documentation? Following
                 this logic, we would not
be able to change anything ever. What we should actually
                 do is update the
                 documentation. Ditto for automation.


+1 for updating the automation and documentation. But some
             backward
             compatibility will need to be retained, at least for the
             stable systems like
             RHEL where *other* people may have some automation or
             documentation around it,
             not just us.


Or you could just also create a symlink to the old name and it
will
         always just work.

         rob


     Aren't the symlinks what Martin2 mentioned in second-NACK?

     These new timestamped logs should be combined with the Gabe's
     patches: #5728 (renamed to command name) and #5724 (move to
     /var/log/ipa directory).

     So that there will be e.g.:
     /var/log/ipaserver-install.log ->
     /var/log/ipa-server-install-{timestamp}.log

     /var/log/ipa/ipa-server-install.log ->
     /var/log/ipa-server-install-{timestamp}.log


I wonder if it would be simpler/better to always write to the *.log
file, and then have old logs timestamped rather than write directly to a
timestamped log file?
Then just symlink the original log file in /var/log/ to the new log file
name/location in /var/log/ipa.

For example:
/var/log/ipaserver-install.log ->
/var/log/ipa/ipa-server-install.log <-- We write to this
log (current)

/var/log/ipa-server-install-{timestamp}.log <-- Old log with some date

/var/log/ipa-server-install-{timestamp}.log   <-- Older log with some
date

/var/log/ipa-server-install-{timestamp}.log   <-- Oldest log with some
date

This is way too overengineered for something that should actually be
really simple. I don't care if it is done this way or not, but IMHO it
would be a waste of time. Logs are not API and should not be treated as
such. If it needs to be done differently on RHEL, it should be handled
downstream.

Sure logs are not API but they have been named the same way since
inception (nearly 8 years now). I don't think symlinking to the old
names is a big deal.

It kind of is, since you have to keep the symlink up to date, handle the case when there is a regular file in place of the symlink, and they won't work properly for commands which currently append to their log files rather than overwrite them anyway.

To do this properly, you have to add a new FileHandler with proper options for each old log file. IMHO there is no benefit in doing this upstream, but it is relatively straightforward and isolated to be done downstream.

PermaNACK, the ticket has been moved to Future Releases

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to