The doc looks alright. I think we can pretty much follow it to start dev work.
Just couple things to keep in mind when doing actual implementation:
Thanks. And good luck with the project.
Thanks @chad to share this issue. Couple comments:
@chad no, I do not think we did anything for this item. But with F2F meeting, notification discussion, it can help this one somehow.
@anujgupta Looks like a minor change, think we can approve it if no regression. Please confirm. Thanks.
@anujgupta related to entitlement v2, a behavior change, please review. Thanks
Thanks @divido .
This topic was triggered by log4j security fixes recently.
If there is no functional issue and security issue (basically no concern), I think it is OK for the lib stay behind some.
This is related to Indexer and Search services. But with current code layer out, the actually change need to be at common core lib.
Indexer and Search services using elasticsearch (client) lib to communicate with ElasticSearch service.
The elasticsearch service is at 7.11 with latest M10 code (based on IBM). But, the elasticsearch lib used by common core lib is at 7.8.1.
Related to recent log4j fixes, wonder if we need to move elasticsearch lib to a recent release?
Good news and good approach. Thanks.
@ChrisZhang I possibly do not have time to dial in Jan 10th dev daily call. For this item, I understand the approach and pros, cons. I have no concern.
One question: @zhibinmai assume we can use combination of wildcard and list, for example:
“kind”: “a:b:c:*,a:e:c:*”
I agreed with analysis #69 (closed). Also agree that a virtual property approach is a best.
My questions are about (1) how to maintain the virtual properties (think of not only related to this topic, but may extend to other properties), and (2) where to maintain these "virtual" properties. I am with the concern of "scalability/agility problems" and also future maintenance and extensions.
@anujgupta @shamazum Please check this item.
Comment from Anuj #49 (comment 58239) is valid, we need to standardize DAG packaging -> deployment -> integration.
@ChrisZhang @debasisc @anujgupta @shamazum @shrikgar
IBM OSDU/ODI is a hybrid-cloud/on-prem solution. So we document the 3rd party utility service versions and also when the cluster admin deploy/install these services, they know which version to deploy.
But, if this items affects core libs and IBM need some updates (due to the changes from OSDU), we need to check to see how to support.
I do not think this item is high priority to IBM (if not break core libs or other cloud provider functions).
fyi @anujgupta @shamazum @shrikgar @ChrisZhang I did a scan for all ‘critical’ and ‘high’ severity vulnerabilities for CRS Conversion service and Unit service. https://community.opengroup.org/groups/osdu/platform/-/security/vulnerabilities/?severity=CRITICAL&severity=HIGH
All issues are related to unit test, and not with any "product" code. So I think we are cool here. I do not think we need to fix anything basically.
If we really need to fix, I can contact Azure team, since almost all are related to Azure test.
Thanks
Thanks @sacha for explanation. For "discuss the new repository separately", appreciate if you can share your plan, so team will have better understanding of this new part. I understand this MR is not a place to discuss this topic, apologize to put here. Please point me to the correct issue. Thanks much.
Thanks @sacha get it, so I might put comment into a wrong MR. @anujgupta @dsouzawalter
@DiegoMolteni @sacha I noticed this change and related are big and also introduce some new package, such as https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite. In order for CSP team to better plan the workload, can you please share your changing plan? arch design, or ARD issue? Thanks.
@ChrisZhang I could not find any reason behind versioning support for utility services with this ADR except a post from @Wibben asking about it from osdu/platform/system/partition!80 (comment 63690).
And from osdu/platform/system/lib/core/os-core-common#47 (closed), I could not find it easily neither.
Yes, I think we can go ahead with this adr, and continue discussion with osdu/platform/system/home#89.
Related to osdu/platform/system/lib/core/os-core-common#49 (comment 64162) discussion, @ethiraj , I agreed with you and would start with the OSDU Security and Enterprise Architect team. Thanks