Prevent admin from acquiring commit lock when another admin has lock

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Prevent admin from acquiring commit lock when another admin has lock

L2 Linker

 

When Automatically Acquire Commit Lock is enabled on Panorama 8.0.10, is there a way to prevent an admin from creating another lock while a different admin already has one?

 

We use shared objects almost exclusively and with four administrators are often in situations where multiple locks are getting created. This leads to reaching out to the other admins to make sure they are done and if it's ok for lock removal so all changes can be commited.

 

Has anyone else experienced this behaviour and either come up with a different setting or work flow that smooths it out?

4 REPLIES 4

Cyber Elite
Cyber Elite

your administrators can also take a config lock when they are making changes to ensure no one else makes changes until they have released both the config and commit locks after pushing a commit

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Cyber Elite
Cyber Elite

@fwmike,

That's kind of the point of that setting actually. I personally follow the following areas to ensure that this doesn't stack up.

 

1) Ideally when the administrator is done working on their changes they would remove their own commit lock, essentially signaling that they're done working on what they needed to. 

2) When the administrator starts to work on changes they take a configuration lock, which would prevent any other person making changes while they are working on what they need. Again, as long as they remove their lock when they are done working on whatever it is they needed to do, this works. If they aren't removing their existing commit locks then you probably don't want to do this. 

3) I have a script that will commit at 2200 everyday. This removes any existing locks and commits the configuration. Therefore everyone knows that they need to either be done with their changes or revert them before 2200; failure to do so is placed on the admin that is working on changes. 


@BPry wrote:

 

3) I have a script that will commit at 2200 everyday. This removes any existing locks and commits the configuration. Therefore everyone knows that they need to either be done with their changes or revert them before 2200; failure to do so is placed on the admin that is working on changes. 


oh wow I like this one for all the wrong reasons 😛

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

@reaper,

Honestly it was one of my favorite things to implement. The other admin liked to leave half finished configurations when they left for the day; since this was put in place it amazingly stopped and I don't have to worry about it anymore. 

 

PS: If anyone likes this idea and implements it do not use commit force, just do a commit. The validation process will catch pretty much any configuration issues that may be present; but if you force the commit you'll probably run into a few instances where you'll break things. 

  • 2636 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!