topic Re: Lock weirdness in API / CLI Discussion

Lock weirdness

Bob_Zimmerman — Sat, 26 Mar 2022 15:23:06 GMT

Currently using APIv1.7.1, and I've noticed some weird behavior with write locks on objects. When I make a call to change an object like so:

mgmt_cli -s session.txt -f json set host uid f752bfcd-8194-4831-a8cf-16dabecbac73 ipv4-address 10.20.30.40

the data returned by the call includes meta-info.lock: "unlocked" and read-only: true. When I later show the same object from the same session like so:

mgmt_cli -s session.txt -f json show host uid f752bfcd-8194-4831-a8cf-16dabecbac73

the data returned has meta-info.lock: "locked by current session" and read-only: false.

Why the difference?

Separately, is there a way in the API to see which objects have a lock besides just downloading everything from scratch? 'show sessions' for the session with the lock shows it has a lock, but doesn't tell you what it has locked. Specifically, I want to be able to tell what objects have been locked since I started my session, and which sessions have locked them.

Re: Lock weirdness

PhoneBoy — Mon, 28 Mar 2022 19:25:18 GMT

Paging @Omer_Kleinstern

Re: Lock weirdness

Bob_Zimmerman — Sun, 23 Oct 2022 18:46:03 GMT

Coming back to this, I put together a brief script demonstrating the issue:

[Expert@DallasSA]# mgmt_cli -r true login > session.txt [Expert@DallasSA]# UUID_TO_CHANGE=$(mgmt_cli -f json -s session.txt show hosts limit 1 | jq '.objects[0].uid') [Expert@DallasSA]# mgmt_cli -f json -s session.txt show host uid "$UUID_TO_CHANGE" details-level full | jq '{readOnly:."read-only",metaInfo:."meta-info"}';mgmt_cli -f json -s session.txt set host uid "$UUID_TO_CHANGE" comments "Testing a change" details-level full | jq '{readOnly:."read-only",metaInfo:."meta-info"}';mgmt_cli -f json -s session.txt show host uid "$UUID_TO_CHANGE" details-level full | jq '{readOnly:."read-only",metaInfo:."meta-info"}' { "readOnly": false, "metaInfo": { "lock": "unlocked", "validation-state": "ok", "last-modify-time": { "posix": 1637433240653, "iso-8601": "2021-11-20T18:34+0000" }, "last-modifier": "WEB_API", "creation-time": { "posix": 1637433240653, "iso-8601": "2021-11-20T18:34+0000" }, "creator": "WEB_API" } } { "readOnly": true, "metaInfo": { "lock": "unlocked", "validation-state": "ok", "last-modify-time": { "posix": 1666550291300, "iso-8601": "2022-10-23T18:38+0000" }, "last-modifier": "WEB_API", "creation-time": { "posix": 1637433240653, "iso-8601": "2021-11-20T18:34+0000" }, "creator": "WEB_API" } } { "readOnly": false, "metaInfo": { "lock": "locked by current session", "validation-state": "ok", "last-modify-time": { "posix": 1666550291300, "iso-8601": "2022-10-23T18:38+0000" }, "last-modifier": "WEB_API", "creation-time": { "posix": 1637433240653, "iso-8601": "2021-11-20T18:34+0000" }, "creator": "WEB_API" } }

Still on API v1.7.1 (R81 jumbo 74).

The main command generates a before-change output, the output from the change call, then an after-change output. The change output updates the read-only property to true, and the meta-info.last-modify-time gets updated, but the meta-info.lock property stays "unlocked". Then immediately after the change, the read-only property goes back to false and the meta-info.lock updates to say it's locked by the current session.

Is this expected behavior? Seems weird to not immediately show the object is locked by the current session. The brief trip through read-only: true is also strange.

Re: Lock weirdness

PhoneBoy — Mon, 24 Oct 2022 17:58:33 GMT

Sounds weird to me also.
@Omer_Kleinstern

Re: Lock weirdness

Omer_Kleinstern — Wed, 26 Oct 2022 21:10:50 GMT

Looks like an issue.

Why is this property interesting in this case? When a SET command on a network object is completed successfully, the object is definitely locked by the current session.

Re: Lock weirdness

Bob_Zimmerman — Wed, 26 Oct 2022 22:11:21 GMT

It's only really an issue because I would like my data import to be simple. I want to avoid special cases like "I just set this object, so ignore the meta-info fields the returned data has, and use this meta-info I create locally instead."

The language I'm using is aggressively asynchronous and reactive. All of my response handling (and therefore data importing) is in a callback closure, which doesn't necessarily get to know about the request which resulted in the closure being called. I can spin up a background thread and force a synchronous call (thereby maintaining access to call input), but that's gross for other reasons. Still, might be my best option for now.

The language is also strongly-typed, which makes the wide assortment of objects returned by 'show objects' interesting to handle, but that's pretty far off-topic. 😉