-
Notifications
You must be signed in to change notification settings - Fork 2
Registry workshop 2023‐08‐22
- Review current status and plans
- Q&A
Meeting Recording: To Be Added
- Disk space and alerts
- Registry sweeper:
- provenance
- ancestry
- repairkit
- legacy
- Multitenant registry, on MCP
- API, bug fixes
- Notebooks (OREX/OVIRS, Galileo/MAG with pyWWT, BepiColombo, Messenger): https://github.com/NASA-PDS/search-api-notebook/
The user visualization of data is going to be developed as part of the web modernization effort.
We also want to develop a basic html view (with no stype) from the API for users to be able to visualize the metadata in a friendly way. Ticket created https://github.com/NASA-PDS/registry-api/issues/374
As a reminder, the API (Application Programming Interface) is meant for machine to machine interface so the human friendly vizualization will not be developed in this component.
How the disk space currently happening on the multi-domain setup will be managed in the multitenant registry (Pat):
We are thinking of using the serveless OpenSearch option which enables auto-scaling (e.g. add automatically resources to the cluster when needed).
Ticket has been created https://github.com/NASA-PDS/registry-api/issues/372
Ticket has been created https://github.com/NASA-PDS/registry-api/issues/371
See ticket https://github.com/NASA-PDS/registry-api/issues/353
Ticket created https://github.com/NASA-PDS/registry-api/issues/373
Should we use the statistics on the volume of the labels to plan the space, costs (could be done as part of the review of mission) (Anne):
Currently, we can use the autoscaling options to adapt the computing resources to the needed labels but in the future we might need metrics with statistics on the number and size of the labels per mission to estimate and plan the associated costs.