Written by Douglas McPherson
Solutions Consultant at Juniper
Previous Article: On Box Storage: Option 1 - Flat Files as a Data Store
Next Article: On-Box Storage: Option 3 - Utility MIB as a Data Store
This applies to SLAX version 1.0 and higher.
Description
Quite often, scripts will have operational parameters that differ based on device, site, performance considerations, etc. Those parameters should to be separated from the script logic so that they can be modified externally to the script and read in by the script at run-time. This eliminates any need to change the script code if those parameters change. The JUNOS configuration provides a means to store your script’s configurable parameters: By using a combination of JUNOS configuration groups and apply-macros, you can store any arbitrary set of data (typically name/value pairs) that your script may require as configuration parameters.
You can also use apply-macros as a mechanism to “tag” portions of a configuration (e.g. specific interfaces) that your script may want to act on. E.g. add “apply-macro monitor-me” to one or more interfaces. That can provide a convenient way for your script to identify ‘items of interest’ from the local configuration at run-time.
Finally your script can also use apply-macros create “cookies” in the device config. These “apply-macro cookies” can persist across script executions and can be useful for scripts to (for example) keep track of what items a previous script instance may have already changed in the configuration -- and when.
Pros
- Separates your configuration from your running code
- Makes script deployment and updates much easier
- Your “private” script configuration data inherits benefits of JUNOS configuration support features (e.g. sync to other REs on commit-sync; getting backed up with config, etc. As a consequence, the JUNOS configuration file is probably the most reliable (and obvious) place you could save application configuration.
Cons
- Storing data in the configuration requires a configuration commit, and commits bring with them a certain amount of overhead. The “best” candidate for storing data in the configuration would be the configuration data that a script uses, since it doesn’t change very often, and is changed manually.
- Apply-macros as “configuration cookies” generated by a script should only be used as a last resort, due to commit overhead. Also, any script that generates configuration changes should exercise great care to combine all changes into a single commit operation. (I.e., be wary of loops that contain commit operations.)
Gotchas
- Do NOT use the configuration to store data that changes a lot (e.g. counters between polling intervals). That’s just being silly and abusive.