Driver private data was designed to store items that drivers can manipulate, along the design, we may have percolated the idea that driver_private_data is analogous to any other table that is part of the Manila database schema, it isn't.
Manila database has hooks, and there are genuine use cases when Administrators of a Manila installation can access or manipulate data outside of the manila-api (that's the reason why manila-manage exists). Our database schema thus has a contract on upgrades or retention for audits. The same thing cannot be said of driver_private_data. Drivers are free to store whatever they want, since it is a key-value store, and there are no hard-binding upgrade or retention procedures as opposed to any other table/store that is part of the schema.
With that said, I think we should hard delete rows from this store, there is absolutely no valid reason why data deleted by the driver needs to be accessible after deletes.
Driver private data was designed to store items that drivers can manipulate, along the design, we may have percolated the idea that driver_private_data is analogous to any other table that is part of the Manila database schema, it isn't.
Manila database has hooks, and there are genuine use cases when Administrators of a Manila installation can access or manipulate data outside of the manila-api (that's the reason why manila-manage exists). Our database schema thus has a contract on upgrades or retention for audits. The same thing cannot be said of driver_ private_ data. Drivers are free to store whatever they want, since it is a key-value store, and there are no hard-binding upgrade or retention procedures as opposed to any other table/store that is part of the schema.
With that said, I think we should hard delete rows from this store, there is absolutely no valid reason why data deleted by the driver needs to be accessible after deletes.