<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffcc">
Hi Don, <br>
<br>
I responded that they would need to install the node using the
script to have a working model of the node. The installation would
install will install and setup the key pieces on the node side of
the equation, namely the access logging table and the filter in
front of the TDS. As for the ability to fetch the access log data,
I have provided the complete client side tool for making this
happen. Please let me know specifically what further assistance is
needed, as far as I know everything is a go.<br>
<br>
On 3/18/11 11:25 AM, Don Middleton wrote:
<blockquote cite="mid:02831A41-60BE-494E-9AD3-9436B5C64A14@ucar.edu"
type="cite">Thanks for the response on the registry topic, Gavin.
Can you also respond to Nate's metrics question at the beginning
of the thread? There has been a desire and intent to get metrics
support into 1.3, but we're just about out of time on it. There
needs to be a viable service up such that development and
integration testing can be done. Otherwise, this may have to be
pushed out to a later release.
<div><br>
</div>
<div>thanks - don</div>
<div><br>
</div>
<div><br>
<div>
<div>On Mar 18, 2011, at 11:53 AM, Gavin M. Bell wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div text="#000000" bgcolor="#ffffcc"> Hello Team, <br>
<br>
So indeed you guys are all correct, thanks for responding
to Bryan giving him a good context in which to think about
the registry service. Nathan, indeed as you indicated
there are points of integration that we need to touch base
on. I think next week would be a good time to do so. It
would be good to get on the same page with the xsd. I am
not sure which version you are using and I discovered a
few more modifications that had to be made, which also
simplifies things as well. We have to make sure we
capture all the information and agree on the xsd
organization.<br>
<br>
Indeed the registration information will be able to be
easily aggregated and disseminated and as you and Estani
mentioned, cached.<br>
<br>
On 3/18/11 7:13 AM, Nathan Wilhelmi wrote:
<blockquote cite="mid:4D8368A6.5020607@ucar.edu"
type="cite">
<pre wrap="">Hi Estani,
The caching you describe is implemented in the gateway now. All the
registry information is persisted in the database and the code that
synchronizes with the registry is decoupled from the parts that use the
registry information. As such if worst came to worst one could directly
modify the database if a change was needed and the service is down.
-Nate
On 03/18/2011 04:21 AM, Estanislao Gonzalez wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Bryan,
I don't think it is important to be available 24x7. I hope (probably is
not developed, but will be pretty simple to do) that the Gateway caches
the last registry document found, so that it can be still restarted
without problem if precisely at that moment PCMDI's central registry is
not available.
The worst case scenario would be if someone wants to install a Gateway
anew and at precisely that moment the registry is down. this could be
solved by packing a "pre-cached" version of the registry with it (not
that I think this will be that important, as adding this new Gateway to
the federation will take time).
So while the server is down, no new Gateway can be added to the
federation, nor any other changes be done. But the federation itself
should work without a hitch.
But perhaps I'm missing something here...
Thanks,
Estani
Am 18.03.2011 10:15, schrieb Bryan Lawrence:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Gavin
What will the API be to this registry?
What service level with PCMDI provide for it (since it's going to have
to work 24x7 globally)?
Thanks
Bryan
</pre>
<blockquote type="cite">
<pre wrap="">We will have a single registry, it should be served from PCMDI on
pcmdi3. The esgf nodes will all be coded to set pcmdi3 as the
default location for this registry. Indeed coordination with Nate
and Neill and Rachana will have to take place. I suspect that early
next week will be that time. Stay tuned, we'll make this happen.
;-)
On 3/17/11 8:32 AM, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:philip.kershaw@stfc.ac.uk">philip.kershaw@stfc.ac.uk</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So long as we are co-ordinated on this. Will we have a single
registry for the federation or many? I'm opening that question
more widely to all …
</pre>
</blockquote>
</blockquote>
<pre wrap="">--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848;
Web: home.badc.rl.ac.uk/lawrence
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
esg-gateway-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:esg-gateway-dev@mailman.earthsystemgrid.org">esg-gateway-dev@mailman.earthsystemgrid.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.earthsystemgrid.org/mailman/listinfo/esg-gateway-dev">http://mailman.earthsystemgrid.org/mailman/listinfo/esg-gateway-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
--
"Never mistake a clear view for a short distance."
-Paul Saffo
</pre>
</div>
_______________________________________________<br>
GO-ESSP-TECH mailing list<br>
<a moz-do-not-send="true"
href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a><br>
<a class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
--
"Never mistake a clear view for a short distance."
-Paul Saffo
</pre>
</body>
</html>