Judah Scott writes: >When a configuration change happens simultaneously as an admin is building a >candidate config to be commited...
Any config related changes should be protected by locking the configuration (via the "lock-configuration" RPC). The "jcs:load-configuration" template does this for you, and you can look at it (in junos.xsl) for do-it-yourself clues if you need them. >Do the scripting changes get incorporated into this candidate config or are >they commited through another channel? Op scripts can only make normal changes to the candidate config. Long answer: Commit scripts can emit both normal changes and "transient" changes, and an op script can make data (say by defining an apply-macro) that will trigger an op script to make transient changes, but an op script cannot do these itself. >Does the user editing the config see the changes being added to his config >changes or are the scripting changes applied in the background to the >running config? op script changes are normal candidate config changes, so you'll see them in the normal "show" output. >Does the 'config exclusive' mode block the script? Yes, since no one can change the config if anyone holds the exclusive lock. >Does config private/dynamic affect this behavior? You can open a private config via an op script, but typically this isn't needed. The window of change should be small, so a lock will not affect other users and the script will likely not be able to resolve conflicts if the merge during the commit of the private config fails. Please let me know if you need more details or if you have other questions. Thanks, Phil _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp