Undocumented VAG param for SF back-end, and Trident behavior when it's provided

[scaleoutsean]

I had this issue opened once open but it was closed. I'd still like to have the current behavior documented.

a) Current documentation mentions that VAGs are supported, but not used by CSI Trident. But non-CSI Trident is still supported, so the parameter should be documented (volumeAccessGroupID, I presume?)

b) For pre-CSI Trident, it says "If you’re modifying the configuration from one that is using the default trident access group to one that uses others as well, include the ID for the trident access group in the list." There are no examples of this list, I assume it's volumeAccessGroupID: [vagid1,vagid2, vagid3] as identified by VAG IDs (int64)?

c) In "Using Access Groups" (link at the bottom) it says "In addition, if using Trident in CSI mode, you can safely ignore this section. Trident uses CHAP when installed as an enhanced CSI provisioner." Okay, it can be ignored. But if it's configured ("UseCHAP": true + VAGs are defined), will Trident create the volume and add it to VAG defined in back-end? Or err? Or ignore VAG info? Further below it says "If CHAP is disabled it expects to find an access group called trident unless one or more access group IDs are specified in the configuration" but not what happens if CHAP is enabled and VAG ID provided.

Additional context

• CSI Trident defaults to CHAP and that's fine. But if CSI Trident back-end configuration file uses CHAP and VAGs, there are more possible approaches than the Trident documentation.
• Since VAG configuration is already built-in, I would like to know if VAG info can be used to enhance worker segregation or Virtual Storage Pools.
• Current SolidFire back-end configuration options (v21.04)
• Current information about Using access groups with SolidFire

[clintonk]

Thanks, @scaleoutsean. This is timely, as Trident 21.07 will remove support for OCP 3.11 along with all pre-CSI versions of Kubernetes. @netapp-amitha