Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMIP6 Staging index vs copy of remote CMIP6 records? #48

Open
sashakames opened this issue Mar 14, 2025 · 2 comments
Open

CMIP6 Staging index vs copy of remote CMIP6 records? #48

sashakames opened this issue Mar 14, 2025 · 2 comments

Comments

@sashakames
Copy link

Given the CMIP6 closing deadline it is unlikely that CMIP6 will change. Having it r/w with a staging index will require a very large staging index for the collection. Instead it would be a greater benefit to consider adding the UK/EU/AU entries so they will remain discoverable by users of our sites. Just a thought if we are provisioning multiple indexes with very large capacities.

Perhaps we can use the CMIP6 staging initially and then decommission the index once the records are finalized? that way the resources could be re-provisioned.

The UK/EU/AU records can be retrieved from LLNL Solr as we have the replica shards from all.

@jpnavarro
Copy link
Collaborator

jpnavarro commented Mar 14, 2025

When is the closing deadline for CMIP6 publishing, and when we would transition it to read-only? Although we haven't formally discussed how we transition read-write to read-only. I think you are right, that transition would involve getting rid of the staging index used to publish and update metadata.

How many Dataset and File metadata entries are in the UK/EU/AU CMIP6? Would these metadata entries change and need to be refreshed once they were first loaded?

@sashakames
Copy link
Author

April 7 for "original" publication. April 20 for final LLNL replica publishing, other sites would sync (not a hard date but 90% likely to stick).
We would do the UK/EU/AU as a one-time load and that would be presumed read-only.

We will need to process retractions and data relocations as exceptional cases, which would apply to anything, as eg. any site could just drop out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants