updating key names to make code work against opendes tenant
- [YES/NO] I have added an explanation of what changes in this merge do and why we should include it?- [YES]
- [YES/NO] I have updated the documentation accordingly. [N/A]
- [YES/NO/NA] I have added tests to cover my changes. [N/A]
- [YES/NO/NA] All new and existing tests passed.[YES]
- [YES/NO/NA] My code follows the code style of this project. [YES]
- [YES/NO/NA] I ran lint checks locally prior to submission. [N/A]
What is the issue or story related to the change?
Recently we have update the infrastructure against which Ci/CD pipelines run to become DP complaint. In this process we have moved away from having a single resource containing all the azure resources. Now each tenant has it's dedicated resource group. The naming convention of various keys in KV has also changed. e.g. erstwhile
cosmos-key is now called
opendes-cosmos-key for a tenant named
High level design:
- The purpose of this MR is to make code changes work against any one tenant. That one tenant is
opendesin this case. Hence updating the key names according to above mentioned convention. Now keys are called
- Updated the UTs
- updated the deployment.yaml file to reflect latest names of variables in key-vault
Issue: Not running ITs. One integration test fails in azure environment due to a certain behaviour of Istio. Details here: osdu/platform/system/lib/cloud/azure/os-core-lib-azure#1 (closed)
Does this introduce a breaking change?
- [YES/NO] NO
- Please provide an ETA when you plan to review this MR. Write a comment to decline or provide an ETA.
- Block the MR if you feel there is less testing or no details in the MR
- Please cover the following aspects in the MR -- Coding design: <Reviewer1> -- Backward Compatibility: <Reviewer2> -- Feature Logic: <Logic design> -- <Any other context mention here> OR -- <Component 1>: <Reviewer1> -- <CosmosDB>: <Reviewer2> -- <ServiceBus> <Reviewer3> -- <Mention any other component and owner>