[Go-essp-tech] Federation Registry Discussion

Estanislao Gonzalez estanislao.gonzalez at zmaw.de
Tue Feb 22 05:49:28 MST 2011


Hi Rachana,

This is great. This is something I think we will all agree on. Without 
it the federation will be soon unmanageable in my opinion.

I have a couple of remarks regarding the PKI:
- I'd suggest we concentrate on one of the two forms of storing the CAs, 
preferably the PEM certificates. The node/gateway can then use a script 
to generate the truststore periodically or, better yet, on demand. This 
will avoid problems regarding inconsistencies.
- by embedding the PEM certificates in the xml file both registry and CA 
information can be held together from the very beginning.

And regarding the xml file exchange format, this is something that 
should be discussed between the registry service and the node/gateway 
developers. Still I just wanted to point out that the GatewayNode does 
not contain the Gateway name, which is rather important.

On the other hand, the idea of using git as an ingest engine seems IMHO 
perfect to start with. I would then propose that every institution 
manage it's own project (one per gateway and might be hosted anywhere) 
where all the required directories and files are listed and kept up to 
date (but only store PEM certificates, no truststores ones). Then PCMDI 
can have a "repository" project linking at each subproject named simply 
after the gateway name (keyword: git-submodule). This way only the 
gateway admins have write access to their respective projects and PCMDI 
to the central repository (scripts for transforming PEM into truststore, 
creating tars, etc). This helps keeping things tidy and properly 
administrated in my opinion. The node manager can have access to the 
same git repository of the owning gateway and update there the required 
data (Service endpoints, CAs, etc). PCMDI will periodically update all 
submodules and generate the required files (tar balls, etc) which can be 
accessed from every node/gateway with read-only rights.

This can evolve later on to services that upload/download data from the 
registry without using git.

Just an idea...

Thanks,
Estani

Am 22.02.2011 00:10, schrieb Rachana Ananthakrishnan:
> For the next release, we are targeting a federation registry that will provide a store for information about the various ESGF nodes and services, and also the trusted CA information. This page provides some background on the work, and also link to the proposed schema to represent the information:
>
> http://esgf.org/wiki/FederationRegistry
>
> Neill has completed work on ingestion of this data: that is form to obtain the data about a node, and communicate it to a service. Gavin is now working on integrating it with the Data Node Manager, such that the data is stored on a central server at PCMDI and then can be downloaded by other nodes.
>
> Please review and comment.  The document is still sparse on the protocol for exchanging this information, but I am initiating this discussion so we can drive to consensus on the schema atleast.
>
> This service is critical in keeping meta data about the federation curated and distributed, so should be a high priority for next release. It would be useful to table this topic on the next go-essp call. (Not sure if we plan for one tomorrow, Feb 22)
>
> Thanks,
> Rachana
>
> Rachana Ananthakrishnan
> Argonne National Lab | University of Chicago
>
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech


-- 
Estanislao Gonzalez

Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany

Phone:   +49 (40) 46 00 94-126
E-Mail:  estanislao.gonzalez at zmaw.de



More information about the GO-ESSP-TECH mailing list