Xiaoxia: to send out an instructions note to each GS instance, including their confirmation of the documentation and also asking for comments if there are, and the detailed timeline
Secretariat to send out a notification email to all WIS2 nodes operator about the migration of new Topic Hierarchy starting from 4th December to end of February
Rémy: to send an email to three Global Cache operators (DWD, JMA, SYNOPTIC) regarding the transition plan of merging the country and center-id, asking the operators to confirm their readiness (time needed) to support at least one option.
Kenji and Kai: to evaluate the impact of changes on the software systems regarding the merge of country and centre-id and confirm when the transition can begin.
Hassan: to send out a reminder to all participants to attend ET-W2AT (13-15 November, USA) 1) to review the current Kanban · WIS2 - the everything list (github.com) before the meeting in USA. 2) to confirm the current structure of WIS2 Guide and WIS2 transition Guide, to make sure no missing items
Data will always be made available via a MQ message that points to where the data is for download; with an optimisation to embed small data in the message [approved]
Adopts the MQTT 3.1 and MQTT 5 in WIS2.0
Shared services approach approved by the team (Global Cache, Global Broker and Global Discovery Catalogue)
No requirement for NC/DCPC to connect to ALL instances of a shared-service
NC/DCPC MUST connect to at least one instance of a shared service, and SHOULD connect to two or more instances of a shared-service
NC/DCPC connects directly to the shared-service instance(s) - not via their GISC
No requirement for all-to-all fully meshed connection
There must be more than one instance of each shared service
Global Monitoring approved as shared service
There needs to be automated service monitoring of the WIS2 system from day 1
Global Cache will hold "file" Data Objects - same as how "file" Data Objects are shared on the GTS
Data Consumers who want to browse and download data should use the originating center (i.e. NC/DCPC) - Global Cache may be accessed directly, but its primary purpose is to host files that are identified in real-time "data availability" messages. Global Cache does not need to provide a mechanism for Data Consumers to browse the cached content (e.g. file-level STAC metadata). Effectively, this means the cached copy would not be identified in the discovery metadata as a Distribution of the dataset. The discovery metadata record would include "association" links that refer to the originating center for download, and to originating center and Global Brokers for where a Data Consumer can subscribe to updates.
The Global Catalogue will update discovery metadata records to add "association" links for subscription URLs at Global Broker instances
The Global Catalogue advertises the availability of datasets and how/where to access them or subscribe to updates, it does not advertise availability of individual Data Objects that comprise a dataset
Data Consumers should subscribe to Global Brokers to receive "data availability" messages; exceptionally, a Data Consumer may decide to subscribe directly to the local message broker at the originating NC/DCPC; Data Consumers should not subscribe to the local message broker at Global Cache instances.
Global Cache instances and NC/DCPC use consistent topic structure in their local message brokers
Global Brokers should use distinct "channels" to keep messages from originating centers separate from messages originating from Global Cache instances]
Data Consumers will need to implement logic to discard "duplicate" messages
Only embed data in within a message in exceptional circumstances
A global monitoring dashboard for a real-time view
Where metrics are available at NC/DCPC, these _should_ be made available in the standard form, but a provision of metrics is not mandatory. Technical Regulations will include requirements for Sensor centers. Both data and service availability types; at a minimum in terms of how they expose metrics to the Global Monitoring dashboard(s) [the definition of the metrics themselves may be part of other WMO manuals?
WIS2 provides the "plumbing" for data but doesn't define which data need to be shared. WIS2 provides the "plumbing" for capturing [performance] metrics, but we don't define which metrics are needed - this is the responsibility for the other programs/activity
Should be Web based to be aligned with the principles and also should be a self describing and use the openAPI version 3.1 to discover and understand without any need for additional documentation
Use interactive link providing a direct access to the data which not required no further interaction
WIS2 guidance, to be simple to develop simple and flexible description, not be dramatically change in the future, for the API
To determine a communication mechanism with all the wis2node operators about the change of Topic Hierarchy (merge country and centre-id)
Agrees the proposed transition plan, ensuring each Global Cache only needs to support one system during the transition period. (Cache A is ready for transition as soon as possible; Cache B or C stays the same as the current system until the last wis2node migrates)
Title
Creator
Modified
No content found.
No labels
0 Comments
You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.
0 Comments