[j-nsp] purpose of "commit check"?

Chuck Anderson cra at WPI.EDU
Wed Sep 30 11:08:37 EDT 2015


I could be wrong about failed commits logging to "show system commit",
but I thought I saw that at least once.  We log commits with RANCID,
so we get email with the config diffs, including the "show system
commit" output.

Another reason to use commit check--when coordinating changes across
multiple devices, you might want them all to succeed at the same time
rather than having one fail the commit while the others succeed.

On Wed, Sep 30, 2015 at 01:29:52PM +0300, Martin T wrote:
> Harald, Ryan:
> 
> Great tips, thanks!
> 
> 
> 
> Chuck,
> 
> < "commit comment" will log the comment even if the commit fails.
> Doing "commit check" first allows you to avoid this extra comment in
> the "show system commits" log.
> 
> 
> A failed "commit comment" does not create an entry to "show system
> commit" log at least in my Junos 12.3R6.6 :
> 
> 
> [edit]
> root at M10i# run show system commit
> rescue  2014-09-09 14:04:51 UTC by root via cli
> 
> [edit]
> root at M10i# show interfaces ge-0/0/0 unit 0
> vlan-id 0;
> family inet {
>     filter {
>         input input-fw; ## reference 'input-fw' not found
>     }
> }
> 
> [edit]
> root at M10i# commit comment "ingress fw filter to ge-0/0/0.0"
> [edit interfaces ge-0/0/0 unit 0 family inet]
>   'filter'
>     Referenced filter 'input-fw' is not defined
> error: configuration check-out failed
> 
> [edit]
> root at M10i# run show system commit
> rescue  2014-09-09 14:04:51 UTC by root via cli
> 
> [edit]
> root at M10i#
> 
> 
> However, failed "commit comment" does create a log entry to messages
> file. Or does it depend on what exactly failed?
> 
> 
> 
> Phil,
> 
> < Doing a pre-check before a commit is mostly about working up the
> confidence that you're not going to break something.
> 
> Yeah, but if one will "commit" the changes right after(i.e. no
> additional changes to candidate configuration) "commit check", then
> there isn't a difference.
> 
> 
> regards,
> Martin
> 
> On 9/29/15, Bryan Ashley <bashley at streamnetworksinc.com> wrote:
> > Not sure if it's been mentioned or not but another good use of commit check
> > is to confirm a commit confirmed. Typically people will issue a commit
> > confirmed X to automatically rollback a change that didn't work. If the
> > change did work many folks issue a commit to save the change and move
> > forward. The problem with this is both your commit confirmed and subsequent
> > commit burn rollbacks. A commit check will satisfy a commit confirmed
> > without burning an additional rollback.
> >
> >
> > Sent using CloudMagic
> > Email<https://cloudmagic.com/k/d/mailapp?ct=pa&cv=7.3.5&pv=5.1.1&source=email_footer_2>
> > On Tue, Sep 29, 2015 at 11:38 AM, Ryan Harden
> > <hardenrm at uchicago.edu<mailto:hardenrm at uchicago.edu>> wrote:
> >
> >
> > We regularly make large config changes, 'commit check' to confirm there
> > aren't any syntax errors, then save the change as a patch to be applied
> > during a maintenance window.
> > This saves a ton of time during maint windows as we can do configs the day
> > before and at least be sure there are no syntax errors in the patch. Maint
> > windows simply become: load the patch, commit confirmed comment blah,
> > verify, done.
> >
> > /Ryan
> >
> > Ryan Harden
> > Research and Advanced Networking Architect
> > University of Chicago - ASN160
> > P: 773.834.5441
> >
> >> On Sep 28, 2015, at 4:24 PM, Martin T <m4rtntns at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> when I commit the candidate configuration in Junos, I tend to execute
> >> "commit check" and if configuration check succeeds, then I execute
> >> "commit comment <COMMENT>". However, when I think about it, "commit
> >> (comment)" itself should perform those very same checks that "commit
> >> check" does. If yes, then what is the point of "commit check"? Only
> >> purpose I could see is to check the validity of the candidate
> >> configuration in the middle of the configuration process, i.e. to
> >> check if the changes made in candidate configuration so far are fine
> >> but the candidate configuration is not ready to be committed.
> >>
> >>
> >> thanks,
> >> Martin


More information about the juniper-nsp mailing list