[pve-devel] [PATCH manager] Fix #352: Limit the length of backup logs for mails

Thomas Lamprecht t.lamprecht at proxmox.com
Fri May 17 16:07:18 CEST 2019


Am 5/17/19 um 12:16 PM schrieb Dominik Csapak:
> first of all, great that you include tests :) +1

for me also +1 for that one! 

> 
> second, i am not really happy with the approach, since it
> is quite a bit of code, for not that much gain
> 
> On 5/14/19 12:20 PM, Dominic Jäger wrote:
>> When creating a backup the log for a single job can be to big to be
>> transferred by mail. To ensure that mails get delivered nonetheless
>> the amount of lines and their length are limited.
>>
>> Signed-off-by: Dominic Jäger <d.jaeger at proxmox.com>
>> ---
>> The alternative way would have been to build the whole mail, check the
>> size, then go into the string back again to identify parts of which the
>> size explodes.
>> Limiting while building up the string seemed more straightforward and
>> efficient to me. The loss of information is none, as everything is
>> in the task history anyway.
> 
> one approach i would favor is to generate the mail, check the size,
> and only send the initial overview table with a notice that the
> mail was too long and where to find the log
> 
> with your approach, the mail sending is much more complicated,
> for very little gain (a user must probably look for the full
> task log anyway if he wants to get the information) and
> does not even prevent the problem if someone has many vms that
> get backed up (or am i missing that bit?)
> 
> in any case, one comment about the code itself is inline

We control the output format so a simple:

next if $line =~ /^status: \d+/;

would omit all status line, on long backups I really do not see their
use (and if one wants to look more close, the task log _and_ the backup
log (on target storage) includes them. Also the total time + average time
is much more intresteting anyway, for an overview.

Additionally a simple check like you proposed (for really big backup
tasks), where we switch to sending a simple overview table (as HTML
already does) and be good, that should be easier to do and maintain.

> 
>>
>>   PVE/VZDump.pm     | 106 +++++++++++++++++++++++++++++++++++++++++++++++-------
>>   test/Makefile     |   1 +
>>   test/mail_test.pl |  70 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 164 insertions(+), 13 deletions(-)
>>   create mode 100755 test/mail_test.pl
>>
>> diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
>> index 6508c833..62097ad7 100644
>> --- a/PVE/VZDump.pm
>> +++ b/PVE/VZDump.pm
>> @@ -341,6 +341,96 @@ sub read_vzdump_defaults {
>>       return $res;
>>   }
>>   +use constant MAX_LINE_LENGTH => 200;
> 
> why hardcoded here?
> 
> the MAX_LOG_LINES and MAX_LINE_LENGTH are global constants,
> but the $LINES_AT_END (below) is defined in the function
> 
> i would rather have them as parameter, so that
> someone can tune this (if necessary)

it's reused in the test, that's why, I'd guess - but making it dynamic
can work for the tests too..




More information about the pve-devel mailing list