Closed pcuq-ads closed 1 year ago
At first glance, product is in the table product
:
monitoring=# select * from product where filename = 'S3B_SR_0_SRA____20230624T212407_20230624T221337_20230625T002506_2970_081_057______LN3_O_NR_002.SEN3';
-[ RECORD 1 ]--------------+----------------------------------------------------------------------------------------------------
id | 588477
filename | S3B_SR_0_SRA____20230624T212407_20230624T221337_20230625T002506_2970_081_057______LN3_O_NR_002.SEN3
custom | {}
timeliness_name |
timeliness_value_seconds | 0
end_to_end_product | t
t0_pdgs_date | 2023-06-24 22:22:20
prip_storage_end_date | 2023-06-25 00:28:08.763
generation_begin_date | 2023-06-25 00:23:37.695
generation_end_date | 2023-06-25 00:26:08.746
catalog_storage_begin_date | 2023-06-25 00:26:08.754
catalog_storage_end_date | 2023-06-25 00:26:09.481
prip_storage_begin_date | 2023-06-25 00:28:08.583
quality_check_begin_date |
quality_check_end_date |
first_download_date |
eviction_date |
The issue is about field "custom". It is empty on the extract provided.
The field custom
is filled with the information in the metadata extraction's trace :
https://github.com/COPRS/monitoring/blob/76fb79d0b9744d647636c31adab8a05f4905127d/rs-cores/MONITORING/Executables/additional_resources/ConfigMap-ingestor.yaml#L131
And the field is empty in the trace :
The issue seems to be on the TRACE produced by the metadata extraction component instead of the monitoring.
On the example provided with the anomaly, you cans see that there are some metadata associated to the product : "S3B_SR_0_SRA__20230624T212407_20230624T221337_20230625T002506_2970_081_057____LN3_O_NR_002" inside the trace
and we can not see the metadata inside the product table.
Some metadata are well retrieved but not all of them. This is the issue.
@pcuq-ads
The monitoring component is extracting everything that is configured and available in the TRACE :
As you can see, the following fields are either missing or empty :
task.output.timeliness_name_string
task.output.timeliness_value_seconds_integer
task.output.product_metadata_custom_object
Ok. You are right. I thought at first that the full block was part of metadata.
I propose to update the title of this issue and assign the issue to WERUM.
IVV_CCB_2023_w27 : Moved into "Accepted Werum" for correction, Priority major, to be fixed phase 1
Werum_CCB_2023_w27 : Moved into "Product Backlog" for correction (1.14.0-rc2)
Delivered in Production Common v1.14.0 (refer to https://github.com/COPRS/production-common/releases)
SYS_CCB_w29 : Test to be performed after deployment of version 1.14 for both RS CORE Metadata Extraction and Metatada Search Controler. Easy check after 1 week of production.
SYS_CCB_w30 : This issue is fixed with release Production Common V1.14.0.
Environment:
Traceability:
Current Behavior: Trace from Metadata Extraction chain does not provide metadata for some S3 products.
Expected Behavior: Metadata Extraction chain shall provide metadata for all products.
Steps To Reproduce: Check trace for following products:
Test execution artefacts (i.e. logs, screenshots…) Here is a trace from metadata extraction for product S3B_SR_0_SRA__20230624T212407_20230624T221337_20230625T002506_2970_081_057____LN3_O_NR_002.SEN3 We can see that the field product_metadata_custom_object is empty
Whenever possible, first analysis of the root cause Hypothesis : XXX
Bug Generic Definition of Ready (DoR)
Bug Generic Definition of Done (DoD)