You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
import function skips creating paths that have no keys and I think this behavior contradicts the purpose of migrating, because the source and target data structures may not be the same at all cases.
Example;
Here we have a structure where each directory has its own global directory. Some have keys under them, some others do not:
safe tree --keys secrets/data_science
.
└── secrets/data_science/
├── data_engineering/
│ ├── debezium-backend/
│ │ ├── global
│ │ ├── production/
│ │ │ └── global
│ │ │ ├── :JDBC_LOG_DWH_DEBEZIUM_PASSWORD
│ │ │ └── :JDBC_LOG_DWH_READONLY_PASSWORD
│ │ └── staging/
│ │ └── global
│ │ ├── :JDBC_LOG_DWH_DEBEZIUM_PASSWORD
│ │ └── :JDBC_LOG_DWH_READONLY_PASSWORD
│ └── global
└── global
...where we see all paths, with the globals that do not have keys.
When we export this path, the output actually has info about these empty paths, secrets/data_science/data_engineering/global and secrets/data_science/global:
but the import function does not create these paths on the target Vault setup. Hence the target structure fails to resemble the source.
Here's the command I use to do a migration, with safe v.1.8.0, source_vault version 1.11.12, target_vault version 1.15.2:
safe -T source-vault export -a secrets/data_science | safe -T destination-vault import secrets/d
ata_science
wrote secrets/data_science/data_engineering/debezium-backend/global
wrote secrets/data_science/data_engineering/debezium-backend/production/global
wrote secrets/data_science/data_engineering/debezium-backend/staging/global
wrote secrets/data_science/data_engineering/global
wrote secrets/data_science/global
The migrated paths are missing the empty paths: secrets/data_science/data_engineering/global and secrets/data_science/global:
I think we should have an option for the import function that supports creating these empty paths on the target Vault, since some application may depend on them and it would be a burden to create those paths manually on a big migration project.
The text was updated successfully, but these errors were encountered:
import
function skips creating paths that have no keys and I think this behavior contradicts the purpose of migrating, because the source and target data structures may not be the same at all cases.Example;
Here we have a structure where each directory has its own global directory. Some have keys under them, some others do not:
safe tree --keys secrets/data_science . └── secrets/data_science/ ├── data_engineering/ │ ├── debezium-backend/ │ │ ├── global │ │ ├── production/ │ │ │ └── global │ │ │ ├── :JDBC_LOG_DWH_DEBEZIUM_PASSWORD │ │ │ └── :JDBC_LOG_DWH_READONLY_PASSWORD │ │ └── staging/ │ │ └── global │ │ ├── :JDBC_LOG_DWH_DEBEZIUM_PASSWORD │ │ └── :JDBC_LOG_DWH_READONLY_PASSWORD │ └── global └── global
We can also observe it with:
...where we see the paths with keys, and
...where we see all paths, with the globals that do not have keys.
When we export this path, the output actually has info about these empty paths, secrets/data_science/data_engineering/global and secrets/data_science/global:
but the import function does not create these paths on the target Vault setup. Hence the target structure fails to resemble the source.
Here's the command I use to do a migration, with safe v.1.8.0, source_vault version 1.11.12, target_vault version 1.15.2:
The migrated paths are missing the empty paths: secrets/data_science/data_engineering/global and secrets/data_science/global:
...even though the keys are migrated intact:
I think we should have an option for the import function that supports creating these empty paths on the target Vault, since some application may depend on them and it would be a burden to create those paths manually on a big migration project.
The text was updated successfully, but these errors were encountered: