0 | Opening | Jeremy, Rémy | (Rémy) Emphasizes there are numerous open issues discussed over the past weeks and highlights the importance of making decisions to move forward with the pre-operational phase. The approach involves categorizing the issues by urgency. One urgent issue concerns the accuracy of data and metadata flows reported by Kai. The plan is to rewrite the documentation. This process will extend to other issues, with a goal of making decisions and closing issues. (Jeremy) WIS2 documents to be submitted to INFCOM-3 to be held in April need to be finalized by the first week of February, including WIS2 guide, Transition Guidance, Pilot phase final report and preparation of pre-operational phase. Jeremy guides through the organization of current project: https://github.com/orgs/wmo-im/projects/30/views/2, aiming to identify and close various issues. Urgent matters are to be discussed in ET-W2AT to be held in USA next month. Jeremy provides instructions for adding WIS2 related issues (which need to be tagged accordingly) to be better tracked. |
1 | Resolve any “urgent” issues [https://github.com/orgs/wmo-im/projects/30/views/1?filterQuery=status%3AUrgent ] Simple NC/DCPC data sharing in data-and-metadata-flows https://github.com/wmo-im/wis2-guide/issues/29 << easy to resolve I think clarify GDC population at startup https://github.com/wmo-im/wis2-guide/issues/9 << more complex, and relates to how data is published about (mostly) static datasets.
| Jeremy | (Jeremy) https://github.com/orgs/wmo-im/projects/30/views/2 to work on this GitHub project. Discussionhttps://github.com/wmo-im/wis2-guide/issues/29 (Summary background) the current WIS2 guide session 4 (https://wmo-im.github.io/wis2-guide ) is too technical for readers, especially for those implementers. The consensus is 1) to discuss data and metadata sharing introduction in WIS2 guide to be written in which detailed level; 2) location for detailed information (Rémy) 1)emphasizes the need for the separate resource to accurately reflect the agreed architecture, even if it is not directly included in the WIS2 guide. GitHub should be consistent with the new WIS2 guide architecture https://wmo-im.github.io/wis2-guide/ 2)WIS2 guide needs to be user-centric and implementation centric. Specification to be kept for availability but to be published in the Guide. E.g, WIS2 node registration documents, is to showcase which level of details to be included in the WIS2 guide. (Baudouin) graphs is readable. But don’t put everything in one diagram if there are conditions. (Rémy) Tools used for creating the diagrams: Mermaid Markdown (Actions) Tom to open a new issue in the WIS2-Guide repository to check that Mermaid Markdown can be incorporated into the asciidoc publication workflow
(Decisions) The team agrees a) remove WIS2 guide session 4- data and metadata flows and publish in a separate document with the simple data sharing removed. b) an external link to detailed technical specification (no need for INFCOM approval) to be determined (Jeremy) The WIS2 guide is served for users including: end data consumers, those operating wis2node or operating global services. The current session 4 to be removed is more for developers. (Tom) emphasizes the need for a definitive source to explain the workings of the system. Proposes a technical blueprint details to be in a separate document, such as WIS2 Architecture implementation guide? (Weiqing) Does WIS2 guide need to be approved by INFCOM? (Rémy) discussion for external document location is not urgent.
https://github.com/wmo-im/wis2-guide/issues/9 (Jeremy) to treat metadata as Baudouin) No special treatment towards data and metadata. There are two methods to handle it. One is what Rémy suggests, pushing the entire catalog as a file daily, with potential redundancy. The other is the proposed approach, allowing the data provider to set the cache lifetime, which aligns with simplicity and respects the data provider’s specified duration. The decision rests on the group’s consensus. (Decision) Agrees to treat metadata and data at the same level. (Rémy) to publish zip file by GDC, all the wis2nodes, GB, GC can receive the notificationSuggests a method involving the GDC creating a file with all data and publishing a notification message. Each component in WIS2 needs a broker. Each entity needs a local (Tom) Emphasizes the importance of treating metadata and data equally in terms of cache retention. (Kai) Suggests the possibility of different WIS2nodes or Global Services (including GDC) sharing a common broker. (Enrico) GDC, GC, a local broker needs to be known. Needs to be registered. (Tom) GDC needs publishes a daily report to be published. GDC has a local broker. And GB subscribes to GDC. Guide to be updated accordinglymessage that points to the new archive. Acknowledges there is a need to consider various types of reports that may be employed through this mechanism. Expresses readiness to handle the technical aspects, emphasizing the importance of updating the WIS2 guide for clarity on the responsibilities involved in this process. (Action) Jeremy to update the issue. (Action) Tom To start identifying different reports. (Rémy): currently, there are other two repos. One is WIS2 monitoring (more on implementation), the other one is wis2-metric-hierarchy (a follow-up on Topic Hierarchy). Whether to create a New Repo-WIS2 alerting. Rémy will prepare presentation to trigger the discussion on WIS2 monitoring and alerting. (Weiqing) Who decides the duration of data being cached? (Action) Jeremy to create an issue for node notification repo.
merge country and centre-id (Rémy) needs to agree on one approach to move forward (Tom) there will be guidance on name convention of merging country and centre-id (Jeremy) it will be good to have some examples in the comments (Action) Tom will finalize the proposal within TT-WISMD and then present it for approval in ET-W2AT
|