Documentation for common config changes and whether they cause downtime

[mac-chaffee]

Describe the solution you'd like I'm starting to have to implement some "day 2" changes to my Trident backend config, and each change is requiring a lot of testing time to make sure it doesn't break existing volumes.

I think it might be nice to have documentation about which config settings can be changed without having to recreate volumes or cause downtime. Here are some examples:

• Rotating the password that Trident uses
  • The optimal procedure probably involves creating a second user on the SVM, updating the Trident backend config to use the new user, then deleting the old user.
• Adding a new StorageClass with extra settings like encryption, snapshotting, QoS, etc.
  • I think that can be done without downtime by just adding a new "storage" block in the backend config, and adding a corresponding (non-default) StorageClass. Can the default storage class be changed? Can snapshotting be added to existing volumes without having to recreate them?
• Adding a storagePrefix after-the-fact
  • Haven't tested this one yet. Would changing the storage prefix cause the existing volumes without the prefix to be orphaned?
  • UPDATE: Error: could not create backend: unsupported configuration; updating the storage prefix isn't currently supported (400 Bad Request)
• Changing the backend name
• Changing dataLIF
  • Apparently trying to change this results in an error saying it's not supported. Mentioned here.

Describe alternatives you've considered Manually testing each change in a test cluster. Docs could probably still have a disclaimer saying config changes should be tested.

Additional context

Looks like some of these "UpdateTypes" are enumerated in the source code already: https://github.com/NetApp/trident/blob/75ef09cd3c5fc2ea71f9f2930ea2e696d7b015fa/core/orchestrator_core.go#L1161-L1171

[mac-chaffee]

Another idea:

• Moving volumes between backends
  • if that is possible, it may open up new opportunities for gracefully changing config by just creating a new backend with the right config and moving existing volumes over. Could be the way to add support for changing the storagePrefix since the volume could be renamed during the move (although I recognize it may not be that simple).