Subject: [netmod] buffer/file-size (was "Some feedback on syslog-model-03")

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Sat, 4 Apr 2015 03:21:43 +0000

OK - how about something like the following for buffer-size ('type' itself can't have if-feature).  I didn't put it as a 'choice' (i.e. mutually exclusive) in case some implementations allow both limits.

feature buffer-size-bytes {
    description
        "This feature indicates that local memory logging buffers 
         are limited in size using a limit expressed in bytes.";
}
feature buffer-size-messages {
    description
        "This feature indicates that local memory logging buffers 
         are limited in size using a limit expressed in number
         of messages.";
}

leaf buffer-size-bytes {
    if-feature buffer-limit-bytes
    type uint64;
    units "bytes";
    description
        "This leaf configures the amount of memory (in bytes) that 
         will be dedicated to the local memory logging buffer.";
}
leaf buffer-size-messages {
    if-feature buffer-limit-messages
    type uint64;
    units "log messages";
    description
        "This leaf configures the amount number of log messages that 
         Can be stored in the loocal memory logging buffer.";
}

We probably don't need to say "The default value varies by implementation." in the description field because if we don't put a default in the model (and I don't think we should) then the default isn't specified and will be assumed to vary IMO.

For file logging we should probably also capture the two fundamental approaches:  size vs time.   How about this ?

feature file-limit-size {  // <-- replaces the current file-logging-archive-config
    description
        "This feature indicates that file logging resources 
         are managed using size and number limits.";
}
feature file-limit-duration {
    description
        "This feature indicates that file logging resources 
         are managed using time based limits.";
}

container file-logging-action {
    ...
    // drop the file-logging-archive container
    leaf file-number {
        if-feature file-limit-size;
        ... (from current draft v03)
    }
    leaf file-size {
        if-feature file-limit-size;
        ... (from current draft v03)
    }

    leaf rollover {
        if-feature file-limit-duration
        type uint32;
        units "minutes";
        description
            "This leaf specifies the length of time that log events should
             be written to a specific log file.  Log events that arrive
             after the rollover period cause the current log file to be closed 
             and a new log file to be opened.";
    }
    leaf retention {
        if-feature file-limit-duration
        type uint16;
        units "hours";
        description
            "This leaf specifies the length of time that completed/closed
             log event files should be stored in the file system before 
             they are deleted.";
    }    

I'd recommend we drop the file-permission leaf and leave that to vendor specific augmentation. Authorization in network element file systems is too varied across implementations and I'm not sure that many actually configure it directly as part of the syslog config.

Regards,
Jason

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, March 26, 2015 9:13 PM
To: Sterne, Jason (Jason)
Cc: [email-masked]
Subject: Re: [netmod] Some feedback on syslog-model-03

On Fri, Mar 27, 2015 at 12:22:44AM +0000, Sterne, Jason (Jason) wrote:
> 
> -----------------------------------------------
> C) max sizes/numbers for logs
> -----------------------------------------------
> There are a few places where a size is configured (buffer-size, file-size). Implementations will vary on what units are used in a way that isn't really directly convertible (e.g. bytes vs # of log messages).
> 
> For file logging some implementations use a retention time rather than 
> a size limit or file number limit so I'm glad to see an if-feature 
> around this (or remote it and let the vendor augment for that)
> 
> It is probably more common to have a size for the memory buffers so that is probably OK to leave in.
> 
> Whatever sizes remain in the model:
> - remove any default values
> - explain in the description that "This leaf specifies the maximum xyz size.  The units are not specified in this model and varies by implementation (e.g. bytes vs number of log messages)."
>

Assuming that the number of widely used differences is small, I think this should be modeled properly and features may be used to announce which of the options is supported. This way, I can write a robust network management application that does not simply configure 42 and then hopes something meaningful will happen. An API contract needs to be tight to be useful.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>