OS Core Lib Azure merge requestshttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests2023-10-13T17:59:55Zhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/302Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into ...2023-10-13T17:59:55ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into release/0.23**Original MR**: !301
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !301
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/pipelines/new?ref=cherry-pick-for-301)M20 - Release 0.23David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/301Upgrade First Party Library Dependencies for Release 0.232023-10-13T17:59:56ZDavid Diederichd.diederich@opengroup.orgUpgrade First Party Library Dependencies for Release 0.23This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any...This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any library that is older than the previous release will be left as-is, since the upgrade is likely to be more complicated.
Furthermore, the upgrade should only be merged in the CI pipeline reports success.
If this MR has failed, we can spend a little time investigating to see if a trivial upgrade could achieve compatiblity to the new library.
But significant upgrade efforts should not occur on this MR, as part of the release tagging process.
Instead, significant work should be scheduled for a subsequent milestone.
### Dependency Information Before the Upgrade
```
Branch: master
SHA: 9814bd53bf032d3f2b72b6a6c657b7ce4f379cd0
Maven: 0.24.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| os-core-common | 0.22.0 |
### Dependency Information After the Upgrade
```
Branch: dependency-upgrade
SHA: e1461a99a1b903862bdcfcfdf00cb97ca00d4adf
Maven: 0.24.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| os-core-common | 0.23.0 |M20 - Release 0.23https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/299Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.22' into ...2023-07-12T07:46:55ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.22' into release/0.22**Original MR**: !298
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !298
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/pipelines/new?ref=cherry-pick-for-298)M19 - Release 0.22David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/298Upgrade First Party Library Dependencies for Release 0.222023-07-11T21:00:23ZDavid Diederichd.diederich@opengroup.orgUpgrade First Party Library Dependencies for Release 0.22This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any...This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any library that is older than the previous release will be left as-is, since the upgrade is likely to be more complicated.
Furthermore, the upgrade should only be merged in the CI pipeline reports success.
If this MR has failed, we can spend a little time investigating to see if a trivial upgrade could achieve compatiblity to the new library.
But significant upgrade efforts should not occur on this MR, as part of the release tagging process.
Instead, significant work should be scheduled for a subsequent milestone.
### Dependency Information Before the Upgrade
```
Branch: master
SHA: 0c252c9d381150df6ae2cbebef31acacafe766b0
Maven: 0.23.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| os-core-common | 0.21.0 |
### Dependency Information After the Upgrade
```
Branch: dependency-upgrade
SHA: fd5eb95db8bde186e0532f1750b0dccf6ea44981
Maven: 0.23.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| os-core-common | 0.22.0 |M19 - Release 0.22https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/297Added ingest accounts back2023-08-18T12:42:17ZDeepa KumariAdded ingest accounts backAdding back the ingestStorageAccountKey and Name that were removed previously here: https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/231
Workflow is using this property from here: h...Adding back the ingestStorageAccountKey and Name that were removed previously here: https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/231
Workflow is using this property from here: https://community.opengroup.org/osdu/platform/data-flow/ingestion/ingestion-workflow/-/blob/master/provider/workflow-azure/src/main/java/org/opengroup/osdu/workflow/provider/azure/config/BlobServiceIngestClientFactory.java#L41M19 - Release 0.22Deepa KumariDeepa Kumarihttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/296elasticsearchcred using vmcache2023-08-18T12:42:19ZAkanksha Prasadelasticsearchcred using vmcache## Type of change
- [yes] Bug Fix
- [no] Feature
## Does this introduce a change in the core logic?
- [YES]
## Does this introduce a change in the cloud provider implementation, if so which cloud?
- [YES] Azure
## Does this introduc...## Type of change
- [yes] Bug Fix
- [no] Feature
## Does this introduce a change in the core logic?
- [YES]
## Does this introduce a change in the cloud provider implementation, if so which cloud?
- [YES] Azure
## Does this introduce a breaking change?
- [NO]
## What is the current behavior?
ElasticSearch Cred is fetched from redis cache which was causing during update of elastic search primary user secret as 500 ,internal server error.This was majorly because,refresh time of redis is 60 minutes.Hence,in that duration 500 status code was returned
## What is the new/expected behavior?
After the duration of secret rotation completed,search should return 200 success status code
## Have you added/updated Unit Tests and Integration Tests?
yes
## Any other useful informationM19 - Release 0.22https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/295Upgrade First Party Library Dependencies for Release 0.212023-05-20T05:44:36ZDavid Diederichd.diederich@opengroup.orgUpgrade First Party Library Dependencies for Release 0.21This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any...This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any library that is older than the previous release will be left as-is, since the upgrade is likely to be more complicated.
Furthermore, the upgrade should only be merged in the CI pipeline reports success.
If this MR has failed, we can spend a little time investigating to see if a trivial upgrade could achieve compatiblity to the new library.
But significant upgrade efforts should not occur on this MR, as part of the release tagging process.
Instead, significant work should be scheduled for a subsequent milestone.
### Dependency Information Before the Upgrade
```
Branch: master
SHA: a352eaee65df70ac4c6c48992d834a79396bfea7
Maven: 0.21.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ---------- |
| os-core-common | 0.21.0-rc4 |
### Dependency Information After the Upgrade
```
Branch: dependency-upgrade
SHA: 0e278d825b3223aad30b10e6db21442165a85716
Maven: 0.21.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| os-core-common | 0.21.0 |M18 - Release 0.21https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/294remove logs that cause logs quota exhaustion2023-08-18T12:42:21ZYurii Kondakovremove logs that cause logs quota exhaustionHOTFIX.
We saw log quota exhaustion in prod. The biggest culprit was notification service traces. We have identified 3 log entries that appear to be causing the bulk of the issues and these should be removed
1. Log message startswith "...HOTFIX.
We saw log quota exhaustion in prod. The biggest culprit was notification service traces. We have identified 3 log entries that appear to be causing the bulk of the issues and these should be removed
1. Log message startswith "Notification process started for message with id" - from notification service
2. Log message startswith "Start worker task : {messageId" - from **core-lib-azure**
3. Log message startswith "End worker task duration(ms)" from **core-lib-azure**M18 - Release 0.21Yurii KondakovYurii Kondakovhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/293Update RedisClient initialization2023-06-26T08:41:59Zharshit aggarwalUpdate RedisClient initializationUpdate Redis Client to consume Client options and define proper timeouts in RedisConfiguration
In a way we have 3 different types of timeouts
We have expiry for the keys i.e. TTL for keys in redis, RedisConnectionTimeouts and RedisComman...Update Redis Client to consume Client options and define proper timeouts in RedisConfiguration
In a way we have 3 different types of timeouts
We have expiry for the keys i.e. TTL for keys in redis, RedisConnectionTimeouts and RedisCommandTimeout
Defining them separately as the following were not used in optimal way where TTL for keys were used interchangeably with redis command timeouts
Dependent MR - https://community.opengroup.org/osdu/platform/system/lib/core/os-core-common/-/merge_requests/208M18 - Release 0.21https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/292Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.20' into ...2023-04-07T21:03:30ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade First Party Library Dependencies for Release 0.20' into release/0.20**Original MR**: !291
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !291
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/pipelines/new?ref=cherry-pick-for-291)M17 - Release 0.20David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/291Upgrade First Party Library Dependencies for Release 0.202023-04-07T20:14:25ZDavid Diederichd.diederich@opengroup.orgUpgrade First Party Library Dependencies for Release 0.20This automated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any...This automated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to keep the OSDU projects utilizing the latest available code to ensure widespread usage and stability.
However, any library that is older than the previous release will be left as-is, since the upgrade is likely to be more complicated.
Furthermore, the upgrade should only be merged in the CI pipeline reports success.
If this MR has failed, we can spend a little time investigating to see if a trivial upgrade could achieve compatiblity to the new library.
But significant upgrade efforts should not occur on this MR, as part of the release tagging process.
Instead, significant work should be scheduled for a subsequent milestone.
### Dependency Information Before the Upgrade
```
Branch: master
SHA: df0c1f37de091c2d676a3cd6d636b5dbe313a68a
Maven: 0.21.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------------------ | ------ |
| os-core-common | 0.19.0 |
| (3rd Party) org.yaml.snakeyaml | 1.33 |
```
Critical: Found Vulnerable Snake YAML dependency (<2.0)
└─ _Root_
└─ org.opengroup.osdu.core-lib-azure == 0.21.0-SNAPSHOT
└─ org.redisson.redisson == 3.15.3
└─ org.yaml.snakeyaml == 1.33
```
### Dependency Information After the Upgrade
```
Branch: dependency-upgrade
SHA: 7a0f7e5479963c344ae1b3e1336d9def8979aead
Maven: 0.21.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------------------ | ------ |
| os-core-common | 0.20.1 |
| (3rd Party) org.yaml.snakeyaml | 2.0 |M17 - Release 0.20https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/290make redis host key and password key configurable2023-08-18T12:42:23ZMykyta Savchukmake redis host key and password key configurablemake redis host key and password key configurable in order to let storage use the premium redis instance which has more spare capacity to reduce the load on the standard redis instancemake redis host key and password key configurable in order to let storage use the premium redis instance which has more spare capacity to reduce the load on the standard redis instanceM18 - Release 0.21Mykyta SavchukMykyta Savchukhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/289Patch per document2023-03-30T14:53:06ZAlok JoshiPatch per documentIt is a common use-case for end users to want to patch a list of documents with certain metadata attributes.
user makes a PATCH request:
```
{
"query": {
"ids": [
"record1",
"record2",
....It is a common use-case for end users to want to patch a list of documents with certain metadata attributes.
user makes a PATCH request:
```
{
"query": {
"ids": [
"record1",
"record2",
.
.
.
]
},
"ops": [
{
"op": "add",
"path": "/acl/viewers/-",
"value": "acl1"
},
{
"op": "add",
"path": "/acl/viewers/-",
"value": "acl2"
}
]
}
```
The expectation is that all records should have acl1 and acl2 as part of viewers acl. If acl1 or acl2 is already present for any records, it should be a no-op
Consider following scenario:
record1 has acl/viewers: ["acl1"]
record2 has acl/viewers: ["acl2]
This operation (or list of operations), if applied as-is, will create duplicate acl/viewers for certain records. To avoid this, record1 should only apply the second patch and record2 should only apply the first patch. Therefore, we can have a map input where cosmos patch operation can be different for each document. Corresponding mapping for Partition keys is also maintained
This is what the client (i.e. storage) is expected to generate when calling the bulk patch method.M17 - Release 0.20Alok JoshiAlok Joshihttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/288add overload of queryItemsPage with CosmosQueryRequestOptions param2023-08-18T12:42:25ZNeelesh Thakuradd overload of queryItemsPage with CosmosQueryRequestOptions paramadds overload of queryItemsPage with CosmosQueryRequestOptions param. This param can be utilized by query/kind API to shorten continuationTokenadds overload of queryItemsPage with CosmosQueryRequestOptions param. This param can be utilized by query/kind API to shorten continuationTokenM17 - Release 0.20https://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/287Validate data-partition-id in PartitionServiceClient2023-08-18T12:42:27ZAbhishek PatilValidate data-partition-id in PartitionServiceClient## All Submissions:
-------------------------------------
* [YES/NO] I have added an explanation of what changes in this merge do and why we should include it?
* [YES/NO] I have updated the documentation accordingly.
* [YES/NO/NA] I have...## All Submissions:
-------------------------------------
* [YES/NO] I have added an explanation of what changes in this merge do and why we should include it?
* [YES/NO] I have updated the documentation accordingly.
* [YES/NO/NA] I have added tests to cover my changes.
* [YES/NO/NA] All new and existing tests passed.
* [YES/NO/NA] My code follows the code style of this project.
* [YES/NO/NA] I ran lint checks locally prior to submission.
## What is the issue or story related to the change?
-------------------------------------
<!-- Please describe the current behavior that you are modifying, 'or' link to a relevant issue.
Feel free to add references to any design documents you might have shared with the team or any
related MR that you are building on top of. -->
Today we do not validate the data-partition-id because of which inbuilt URI class throws Illegal Argument Exception if an invalid data-partition-id is passed in headers.
For example, if a char `{` is passed into data-partition-id then Illegal Argument Exception is thrown which is ultimately converted into 500 error response by service. Ideally a 4XX response should have been returned.
This PR introduces a validation on data-partition-id which will help in responding back with 4XX response instead of 500.
High level design:
Issue: <!-- Link any __GitLab__ workitem(s) to this pull request. -->
<!-- Please add implementation details of current set of changes and how the code changes are
doing what they are expected to do. Are there any complex loops or designated code blocks that
should be elaborated? Is there some contextual knowledge that the reviewer should be aware of? -->
Change details:
## Test coverage:
------------------
<!-- Mention unit test coverage of changes. -->
## Does this introduce a breaking change?
-------------------------------------
- [YES/NO]
<!-- If this introduces a breaking change, please describe the impact and migration path for existing applications below. -->
## Pending items
----------------
<!-- Are there changes that you'll introduce in upcoming MRs and hence did not add in this one? Next steps of your
feature can also be mentioned here. -->
## Reviewer request
-------------------
- 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>_
## Other information
-------------------------------------
<!-- Any other information that is important to this MR such as screenshots of how the component looks before and after the change. -->M17 - Release 0.20Abhishek PatilAbhishek Patilhttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/286Added missing function for retrieving elastic versions for connected outer se...2023-03-15T04:39:01ZDeepa KumariAdded missing function for retrieving elastic versions for connected outer servicesThe connected outer services for azure do not contain elastic endpoints version. Analyzed the issue from Indexer and Search service and found that the implementation to getAllClustersSettings was missing inside ElasticClusterSettings cla...The connected outer services for azure do not contain elastic endpoints version. Analyzed the issue from Indexer and Search service and found that the implementation to getAllClustersSettings was missing inside ElasticClusterSettings class.
This MR is to add that behavior.M17 - Release 0.20Deepa KumariDeepa Kumarihttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/285Add document id in bulk errros2023-03-10T16:30:38ZAlok JoshiAdd document id in bulk errrosUse cosmosItemOperation.getId() instead of cosmosItemOperation.getItem() to keep the message small
Return document id with errors when performing bulk operation
Will be useful in implementing [ADR](https://community.opengroup.org/osdu/...Use cosmosItemOperation.getId() instead of cosmosItemOperation.getItem() to keep the message small
Return document id with errors when performing bulk operation
Will be useful in implementing [ADR](https://community.opengroup.org/osdu/platform/system/storage/-/issues/124) to get info on recordIds in case of failureM17 - Release 0.20Alok JoshiAlok Joshihttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/284Support for bulk patch2023-03-07T18:19:35ZAlok JoshiSupport for bulk patchAs part of [ADR](https://community.opengroup.org/osdu/platform/system/storage/-/issues/124), we are implementing a solution in Storage service. We want to use Cosmos's implicit patch document support to implement this feature in Storage ...As part of [ADR](https://community.opengroup.org/osdu/platform/system/storage/-/issues/124), we are implementing a solution in Storage service. We want to use Cosmos's implicit patch document support to implement this feature in Storage serivce. This change introduces the ability to do that via this library's methods. We are using CosmosContainer's bulk executor support.M17 - Release 0.20Alok JoshiAlok Joshihttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/283Changes for using SPN token client and MSI token client instead of HTTP clien...2023-08-18T12:42:28ZAbhiram BondadaChanges for using SPN token client and MSI token client instead of HTTP client to fetch tokensTesting procedure: All documentation updated here https://dev.azure.com/OpenEnergyPlatform/Open%20Energy%20Platform/\_wiki/wikis/Open-Energy-Platform.wiki/2104/Testing-OSDU-services'-code-changes-against-a-healthy-instance
This is not ...Testing procedure: All documentation updated here https://dev.azure.com/OpenEnergyPlatform/Open%20Energy%20Platform/\_wiki/wikis/Open-Energy-Platform.wiki/2104/Testing-OSDU-services'-code-changes-against-a-healthy-instance
This is not a compatible branch that we are merging changes to All commits in this branch are made on top of a previous version of core-lib (tag:v0.19.0-rc3). So, need to create another branch and MR. This MR is just for saving changes, getting reviews and resolving the comments.M17 - Release 0.20Abhiram BondadaAbhiram Bondadahttps://community.opengroup.org/osdu/platform/system/lib/cloud/azure/os-core-lib-azure/-/merge_requests/282Changes for using SPN token client and MSI token client instead of HTTP clien...2023-08-18T12:42:30ZAbhiram BondadaChanges for using SPN token client and MSI token client instead of HTTP client to fetch tokensTesting procedure: All documentation updated here
https://dev.azure.com/OpenEnergyPlatform/Open%20Energy%20Platform/_wiki/wikis/Open-Energy-Platform.wiki/2104/Testing-OSDU-services'-code-changes-against-a-healthy-instance
This is not ...Testing procedure: All documentation updated here
https://dev.azure.com/OpenEnergyPlatform/Open%20Energy%20Platform/_wiki/wikis/Open-Energy-Platform.wiki/2104/Testing-OSDU-services'-code-changes-against-a-healthy-instance
This is not a compatible branch that we are merging changes to
All commits in this branch are made on top of a previous version of core-lib (tag:v0.19.0-rc3). So, need to create another branch and MR.
This MR is just for saving changes, getting reviews and resolving the comments.M17 - Release 0.20Abhiram BondadaAbhiram Bondada