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

Martin T m4rtntns at gmail.com
Wed Sep 30 06:29:52 EDT 2015


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
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list