gresockj commented on pull request #5034: URL: https://github.com/apache/nifi/pull/5034#issuecomment-831612138
@jfrazee Good questions. I'm using the term "Vault" as implementation-specific shorthand for HashiCorp Vault (similar to Spring, which calls their HashiCorp Vault service simply "Spring Vault"). I understand there are other similar technologies with similar names, like Azure Key Vault, so that could be a point of confusion. My thought here was to provide a HashiCorp Vault-specific integration point, which can be used in multiple places (Sensitive Properties Providers, Controller Services/Processors, and even ParameterContext providers in the future). If we end up needing an overarching term for generic "vaults", I suggest we use a different term. However, I think the core framework and API already provides this level of abstraction by giving us terms like "Sensitive Properties Provider" (for which there can be a HashiCorp Vault implementation, an Azure Key Vault implementation, etc.). In my mind, the VaultCommunicationService, VaultProperties, etc. are actually fairly specific to HashiCorp Vault, and rather than pushing them into a more generic API, I think we should rely on the already existing APIs like SensitivePropertiesProvider to serve as the extension point for future implementations. What do you think about renaming all of these to HashiCorpVault* to help reduce the confusion? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
