I labeled it as a bug instead of a feature request, because it causes an unintended behavior. In our case, it caused our infrastructure to error out when we tried to restore a backup, because it could not map to the passwords.
Why KV version numbers are important
KV (Key-Value) passwords are version controlled. Each password is assigned a new version number every time it's changed. In gitOps, that version number is very important, because each password placeholder is declared in git as <path:kv/data/foo#3>, #3 being the password version number. This number is incremented in git on password change, which in return signals the gitOps operator (i.e ArgoCD) to update the resource password.
The issue with Medusa
Medusa does not export previous version of the password. It also does not export the version number of that password. When the file is imported back, the version numbers on all KV passwords are reset to 1, causing the platform to not being able to retrieve the passwords.
Solution
export/import the version number of each KV secret
I labeled it as a bug instead of a feature request, because it causes an unintended behavior. In our case, it caused our infrastructure to error out when we tried to restore a backup, because it could not map to the passwords.
Why KV version numbers are important
KV (Key-Value) passwords are version controlled. Each password is assigned a new version number every time it's changed. In gitOps, that version number is very important, because each password placeholder is declared in git as
<path:kv/data/foo#3>,#3being the password version number. This number is incremented in git on password change, which in return signals the gitOps operator (i.e ArgoCD) to update the resource password.The issue with Medusa
Medusa does not export previous version of the password. It also does not export the version number of that password. When the file is imported back, the version numbers on all KV passwords are reset to 1, causing the platform to not being able to retrieve the passwords.
Solution