netapp.ontap version 23.3.0 module is broken for lun mapping

[lyric solstice]

Our critical clusters (fas9500 and AFF-A900) were on ontap 9.15.1P10, and used ansible on tower for our scripting automation. we upgraded netapp.ontap to version 23.3.0, and no issues. one of the things we leveraged is creating/deleting clones with luns. our accounts we created for running scripts have a restricted role that will only allow what it needs to do (only crap companies would insist on admin role)... hence no automation accounts have admin role. all worked well. when I upgraded one of my clusters to 9.16.1P10, and then a part of the script broke. lun mapping no longer works... now 23.3.0 wants to make a query (I assume to check if its an ASA r2 mode host... )... the lun mapping does a "GET /api/private/cli/debug/smdb/table/OntapMode: ['X-Dot-Client-App: netapp.ontap.na_lun_map/23.3.0']" ... the only fix I could find is to downgrade netapp.ontap to version 22.8.0...

Is there a reported bug, or who the heck do i get support help from for this... I just get pass the buck for this... NetApp support is getting worse by the month...

[quartz cove]

22.8.0 is pretty old, did you try newer versions? Support for ASAr2 got introduced in 23.0.0 so maybe try the version before that.

But yes, sounds like a bug or at least a documention issue that certain additional privileges are needed.
Discord is the correct place to report this. Additionally you could also create a Github issue.

Here's the code responsible for this: https://github.com/ansible-collections/netapp.ontap/blob/main/plugins%2Fmodule_utils%2Frest_ontap_personality.py

It has been introduced with 23.0.0.

[lost pilot]

yeah, I can only add to what OG1 said, if you insist on using a restricted role then you have to check on every update (ONTAP update or ansible module update) if you need additional permissions. That's why Best Practice is to se admin role

[lyric solstice]

Listen Darkstar, you naïve special individual who has never had a job in the real world... NetApp spouts security at our monthly meetings and I have and then you have the inexperience to say that it is Best Practice to set admin role... I can only assume that A-Team stands for

[undone kettle]

Check for open bugs here and create one if necessary: https://github.com/ansible-collections/netapp.ontap/issues

The devs are usually quite responsive there.

[lost pilot]

Oh kiddo... you can try and insult me all you want, it doesn't change the fact that those are your two only options. either use vsadmin role which will simply work, or use your own role and check it with every single update.
Most people have test systems to catch these issues and don't simply do updates on their production systems, I assume it's the same with you, seeing as how professional all your installations are, so you should really have spotted that issue on your test systems before it hits production.