GeoSpatial merge requestshttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests2023-12-14T10:21:08Zhttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/177Cherry-pick 'Full Upgrade of First Party Library Dependencies for Release 0.2...2023-12-14T10:21:08ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Full Upgrade of First Party Library Dependencies for Release 0.25' into release/0.25**Original MR**: !176
### 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**: !176
### 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/consumption/geospatial/-/pipelines/new?ref=cherry-pick-for-176)M22 - Release 0.25David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/176Full Upgrade of First Party Library Dependencies for Release 0.252023-12-13T18:55:04ZDavid Diederichd.diederich@opengroup.orgFull Upgrade of First Party Library Dependencies for Release 0.25This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to try to fully upgrade all dependent libraries to see if the latest code will work.
It is expected that these will ...This generated MR upgrades the first party libraries (other OSDU libraries) to utilize the latest release.
The intent is to try to fully upgrade all dependent libraries to see if the latest code will work.
It is expected that these will often fail, since the upgrades were previously rejected for failing pipelines and have not been directly addressed yet.
This 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.
This MR may co-exist with a separate, smaller upgrade MR.
If both pass, this one should be used instead.
### Dependency Information Before the Upgrade
```
Branch: master
SHA: b09a7a1a651f91131d3e9bcab0a60d670db26a81
Maven: 0.26.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | -------------- |
| core-lib-gc | 0.24.0 |
| os-core-lib-aws | 0.23.0 |
| os-core-common | 0.24.0, 0.23.0 |
### Dependency Information After the Upgrade
```
Branch: dependency-upgrade
SHA: 22e050b919f7ea075467ad64528ea7a3e0bcfc1c
Maven: 0.26.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | -------------- |
| core-lib-gc | 0.25.0 |
| os-core-lib-aws | 0.23.0 |
| os-core-common | 0.25.0, 0.23.0 |M22 - Release 0.25https://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/175Cherry-pick 'Reinstate feature service id lr' into release/0.252023-12-12T19:22:57ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Reinstate feature service id lr' into release/0.25**Original MR**: !173
### 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**: !173
### 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/consumption/geospatial/-/pipelines/new?ref=cherry-pick-for-173)M22 - Release 0.25David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/173Reinstate feature service id lr2023-12-12T17:35:25ZLevi RemingtonReinstate feature service id lr## Type of change
- [x] Bug Fix
- [ ] Feature
**Please provide link to gitlab issue or ADR(Architecture Decision Record)**
https://community.opengroup.org/osdu/platform/consumption/geospatial/-/issues/317
## Does this introduce a ch...## Type of change
- [x] Bug Fix
- [ ] Feature
**Please provide link to gitlab issue or ADR(Architecture Decision Record)**
https://community.opengroup.org/osdu/platform/consumption/geospatial/-/issues/317
## Does this introduce a change in the core logic?
- [YES/**NO**]
## Does this introduce a change in the cloud provider implementation, if so which cloud?
- [ ] AWS
- [ ] Azure
- [ ] GCP
- [ ] IBM
## Does this introduce a breaking change?
- [**YES**/NO]
* Provider service will now enforce "/gcz/" in the URL path (before "FeatureServer") to act as the FeatureServer ID
* How to upgrade? - Please update URLs to include "/gcz/"
* You may also download our updated Postman Collection which features the updated endpoints
## What is the current URL?
"ignite-provider/rest/services/FeatureServer/:layer"
## What is the new/expected URL?
"ignite-provider/rest/services/gcz/FeatureServer/:layer"M22 - Release 0.25Levi RemingtonLevi Remingtonhttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/126Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into ...2023-09-04T20:08:18ZChad LeongCherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into release/0.23**Original MR**: !124
### 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**: !124
### 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/consumption/geospatial/-/pipelines/new?ref=cherry-pick-for-124)M20 - Release 0.23David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/125Cherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into ...2023-09-04T18:22:22ZSrinivasan NarayananCherry-pick 'Upgrade First Party Library Dependencies for Release 0.23' into release/0.23**Original MR**: !124
### 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**: !124
### 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/consumption/geospatial/-/pipelines/new?ref=cherry-pick-for-124)M20 - Release 0.23David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/124Upgrade First Party Library Dependencies for Release 0.232023-09-04T19:49:02ZDavid 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: 26c7754c896249dc54d3a275d77ff224793125e3
Maven: 0.23.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| core-lib-gc | 0.22.1 |
| os-core-common | 0.22.0 |
### Dependency Information After the Upgrade
```
Branch: dependency-upgrade
SHA: 9448bf8224584c7104c3965dcff615347046a960
Maven: 0.23.0, gc.0-SNAPSHOT
```
| Maven Dependencies | _Root_ |
| ------------------ | ------ |
| core-lib-gc | 0.23.0 |
| os-core-common | 0.23.0 |M20 - Release 0.23https://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/109Cherry-pick 'Rollback GridGain Version from 8.8.27 to 8.8.13' into release/0.212023-05-26T15:30:14ZChad LeongCherry-pick 'Rollback GridGain Version from 8.8.27 to 8.8.13' into release/0.21**Original MR**: !108
### 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**: !108
### 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/consumption/geospatial/-/pipelines/new?ref=cherry-pick-for-108)M18 - Release 0.21David Diederichd.diederich@opengroup.orgChad LeongSrinivasan NarayananDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/108Rollback GridGain Version from 8.8.27 to 8.8.132023-06-05T22:08:59ZLevi RemingtonRollback GridGain Version from 8.8.27 to 8.8.13## Type of change
- [x] Bug Fix
- [ ] Feature
**Please provide link to gitlab issue or ADR(Architecture Decision Record)**
#237
## Does this introduce a change in the core logic?
- [YES/**NO**]
## Does this introduce a change in t...## Type of change
- [x] Bug Fix
- [ ] Feature
**Please provide link to gitlab issue or ADR(Architecture Decision Record)**
#237
## Does this introduce a change in the core logic?
- [YES/**NO**]
## Does this introduce a change in the cloud provider implementation, if so which cloud?
- [ ] AWS
- [x] Azure
- [ ] GCP
- [ ] IBM
## Does this introduce a breaking change?
- [YES/**NO**]
- It introduces a **fixing** change :)
## What is the current behavior?
GCZ Transformer **cannot** spatially index and load features into an Ignite Cluster Cache hosted on Kubernetes when using GridGain Version 8.8.27.
## What is the new/expected behavior?
GCZ Transformer **can** spatially index and load features into an Ignite Cluster Cache hosted on Kubernetes when using GridGain version 8.8.13.
## Have you added/updated Unit Tests and Integration Tests?
N/A
## Any other useful information
https://opensdu.slack.com/archives/C022X4RC0UR/p1684951520996859?thread_ts=1684922749.325809&cid=C022X4RC0URM18 - Release 0.21Levi RemingtonLevi Remingtonhttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/92Relocate default config files to the core subdirectories2023-06-05T22:08:59ZLevi RemingtonRelocate default config files to the core subdirectories**Changes:**
- Natively support config file accessibility when image creation may sever context between the core code and a config file located in a parent directory
- Update Wiki path references
Directly addresses #238
**Unchanged:**...**Changes:**
- Natively support config file accessibility when image creation may sever context between the core code and a config file located in a parent directory
- Update Wiki path references
Directly addresses #238
**Unchanged:**
Provider config file location remains static, whereas Transformer config file location can still be set away from default location via environment variable or command rule.
**Note:** Build pipeline is failing until core-lib-gcp dependency issue is resolved. See issue here: https://community.opengroup.org/osdu/platform/consumption/geospatial/-/issues/241M18 - Release 0.21Levi RemingtonLevi Remingtonhttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/83Added gc application (GONRG-6593)2023-03-07T07:15:16ZYurii Ruban [EPAM / GCP]Added gc application (GONRG-6593)# Description:
Added application with Google authentication.
# How to test:
1. Run the application
2. Run ignite application
3. Check the results on the gcz map.
# Changes include:
- [ ] New feature (a non-breaking change that adds ...# Description:
Added application with Google authentication.
# How to test:
1. Run the application
2. Run ignite application
3. Check the results on the gcz map.
# Changes include:
- [ ] New feature (a non-breaking change that adds functionality).
# Changes in:
- [ ] GCPM17 - Release 0.20Riabokon Stanislav(EPAM)[GCP]Riabokon Stanislav(EPAM)[GCP]https://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/75Vulnerability fix ibm gcz transformer2023-08-25T22:20:55ZPintu GuptaVulnerability fix ibm gcz transformerFollowing CVE has been fix with this MR :
| cve | link |
|------------------|-------------------------------------------------------------------|
| CVE-2020-9484 ...Following CVE has been fix with this MR :
| cve | link |
|------------------|-------------------------------------------------------------------|
| CVE-2020-9484 | https://nvd.nist.gov/vuln/detail/CVE-2020-9484 |
| CVE-2021-41079 | https://nvd.nist.gov/vuln/detail/CVE-2021-41079 |
| CVE-2022-42252 | https://nvd.nist.gov/vuln/detail/CVE-2022-42252 |
| CVE-2021-22118 | https://nvd.nist.gov/vuln/detail/CVE-2021-22118 |
| CVE-2021-22118 | https://nvd.nist.gov/vuln/detail/CVE-2021-22118 |
| CVE-2022-22968 | https://nvd.nist.gov/vuln/detail/CVE-2022-22968 |
| CVE-2022-22970 | https://nvd.nist.gov/vuln/detail/CVE-2022-22970 |
| CVE-2021-22118 | https://nvd.nist.gov/vuln/detail/CVE-2021-22118 |
| CVE-2022-22968 | https://nvd.nist.gov/vuln/detail/CVE-2022-22968 |
| CVE-2022-22970 | https://nvd.nist.gov/vuln/detail/CVE-2022-22970 |
| CVE-2021-45105 | https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105 |
| CVE-2020-25649 | https://nvd.nist.gov/vuln/detail/CVE-2020-25649 |
| CVE-2020-36518 | https://nvd.nist.gov/vuln/detail/CVE-2020-36518 |
| CVE-2022-42003 | https://nvd.nist.gov/vuln/detail/CVE-2022-42003 |
| CVE-2022-42004 | https://nvd.nist.gov/vuln/detail/CVE-2022-42004 |
| CVE-2020-36518 | https://nvd.nist.gov/vuln/detail/CVE-2020-36518 |
| CVE-2022-42003 | https://nvd.nist.gov/vuln/detail/CVE-2022-42003 |
| CVE-2022-42004 | https://nvd.nist.gov/vuln/detail/CVE-2022-42004 |
| CVE-2021-36090 | https://nvd.nist.gov/vuln/detail/CVE-2021-36090 |
| CVE-2021-36090 | https://nvd.nist.gov/vuln/detail/CVE-2021-36090 |
| PRISMA-2021-0081 | https://issues.apache.org/jira/browse/LUCENE-9981 |
| CVE-2022-25857 | https://nvd.nist.gov/vuln/detail/CVE-2022-25857 |
| CVE-2017-18640 | https://nvd.nist.gov/vuln/detail/CVE-2017-18640 |
| CVE-2022-25857 | https://nvd.nist.gov/vuln/detail/CVE-2022-25857 |Pintu GuptaPintu Guptahttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/63Sprint 272022-12-02T14:30:00ZLevi RemingtonSprint 27## Enhancements
* Add Admin endpoint for manual cache updates `/gcz/transformer/admin/updateCache`
![Screen_Shot_2022-11-15_at_4.22.39_PM](/uploads/9fefc1db34829d536e39466068a1d01b/Screen_Shot_2022-11-15_at_4.22.39_PM.png)
* Added hel...## Enhancements
* Add Admin endpoint for manual cache updates `/gcz/transformer/admin/updateCache`
![Screen_Shot_2022-11-15_at_4.22.39_PM](/uploads/9fefc1db34829d536e39466068a1d01b/Screen_Shot_2022-11-15_at_4.22.39_PM.png)
* Added helper functions to abstract away repeated blocks of code for our FeatureCache Synchronizers
## Fixes
* Transformer: Fix `batchSize` not respected when below 1000
* Provider: Fix koop crashing when spatial intersection using an esriGeometryPoint was attempted
## Docs
* Document new updateCache admin endpoint
* Document `f=geojson` request parameter for Provider-generated Feature Layers
* Document environment variables for specifying YAML configuration files outside of the project directoryM15 - Release 0.18https://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/61Enable configuring Oauth2 Scope, offer Helmchart for deploy in Kubernetes2022-11-01T00:51:15ZRostislav Dublin (EPAM)Enable configuring Oauth2 Scope, offer Helmchart for deploy in Kubernetes- Main: Enable configuring Oauth2 Scope
- Extra: Offer Helmchart for deploy in Kubernetes [see README](https://community.opengroup.org/osdu/platform/consumption/geospatial/-/blob/feature/epm-osdu-1/deploy/README.md)
EPAM Jira: [[EPMOSDU...- Main: Enable configuring Oauth2 Scope
- Extra: Offer Helmchart for deploy in Kubernetes [see README](https://community.opengroup.org/osdu/platform/consumption/geospatial/-/blob/feature/epm-osdu-1/deploy/README.md)
EPAM Jira: [[EPMOSDU-527]](https://jira.epam.com/jira/browse/EPMOSDU-527)Levi RemingtonLevi Remingtonhttps://community.opengroup.org/osdu/platform/consumption/geospatial/-/merge_requests/59Added for k8s client profile.2022-11-18T17:35:50ZAnuj GuptaAdded for k8s client profile.@bhushanrade @shrikgar These are just proposed changes to align on approach if it will work considering our remote is K8S based ignite cluster. This is not tested. If make sense, we can get it reviewed from ESRI team as well.
The change...@bhushanrade @shrikgar These are just proposed changes to align on approach if it will work considering our remote is K8S based ignite cluster. This is not tested. If make sense, we can get it reviewed from ESRI team as well.
The changes are tested for `k8s-profile` and good to merge.M15 - Release 0.18Anuj GuptaAnuj Gupta