[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