Prevent admin from acquiring commit lock when another admin has lock

[fwmike]

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?

[reaper]

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

[BPry]

@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. 

[reaper]

---

@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 😛

[BPry]

@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.