[Go-essp-tech] [esg-gateway-dev] Upcoming gateway/datanode coordination points

Thu Mar 17 08:57:54 MDT 2011

And to add to this... Phil, would you be interested in providing a REST-like interface on top of the core services developed by Gavin, as part of the ESGF source code ?
thanks, Luca

On Mar 17, 2011, at 8:55 AM, Gavin M. Bell wrote:

Philip,

The next esgf node version will contain the ability to produce and make available its registry information The information will be collected and stored in an accessible location via http on the data node.  This will be available shortly (early next week... perhaps even tomorrow if all goes well today, but let's call it early next week in case fit hits the shan - making room for murphy's law).  This is the plan as we all discussed a couple weeks ago, that has not changed.  Also, from the Gateway side of things, as reported by Nate on Tuesday, there is already an uber xml listing available and the ability for the gateway to be configured based on that information.  This will suffice in the first iteration of this process.

It is not that we are stalled... but that it is the nature of the beast of software development that not everything is like clockwork.  No worries. :-)  Using the xsd Neill provided the esgf node will stamp out it's registry info.  The next iterative step will continue as we create a full blown service which is already well underway.

Thanks for keeping us on our toes. :-).... No worries... we are moving with alacrity.

On 3/17/11 7:31 AM, philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk> wrote:

Hi all,

Just to follow up on this thread.  I'm really concerned that this gets
resolved quickly.

Sometime ago now when were considering a way of centralising CA trust root
information we started by hosting them on a simple web page over HTTPS.
Everyone can access them easily with wget or whatever other HTTP client
they prefer to use.  It meant we quickly got up and running with
something, possibly not the best or most elegant solution but it works and
we're still using it now.

Can we not do the same with the registry service?  In the spirit of an
iterative development process, we would have something to get us started
which could then be refactored and improved upon.  As it is though we seem
to be stalled resolving this issue.  This is surely not something we can
afford with a piece that is so critical to the functioning of the
federation.

Cheers,
Phil

On 16/03/2011 03:35, "Rachana Ananthakrishnan" <ranantha at mcs.anl.gov><mailto:ranantha at mcs.anl.gov>
wrote:

Hi,

I have had multiple off-list requests for the registry service
information, and seconding the request from Nate here. The work Neill and
I did was to define the schema and information model, and had a proposal
for a central location to push this and a simple HTTPS download of all
the registered nodes. But Gavin has proposed a solution that has a
tighter integration with the data node manager, and is working on that. I
agree it would be a good point for us to review the service interface and
protocol, and look at integration concerns.

I agree on the REST API for this, and there was suggestions about this
earlier in other discussions. But I think in interest of time, and the
existence of other Hessian services/libraries, this approach was
preferred for now.

Thanks,
Rachana

On Mar 15, 2011, at 10:24 PM, Nathan Wilhelmi wrote:

Hi All,

Looks like we are coming up on a couple of feature points that may
require some coordination between gateway and datanode versions.

Metrics integration: We are working on this now with a target of having
it available for the 1.3 gateway release. What version of the datanode
is required to expose the AccesslogClientService? For a typical
datanode
is this service always configured? This would also be a bump on the
request for information on how to setup this component up on our
systems.

Federation Registry: It's not clear if this has to be a tightly
coordinated release chain or not. Perhaps this would be a good point to
take a group look at the proposed service? This isn't in production yet
so it would be much easier to make any desired changes now rather than
after the fact.

I would like to raise up the intended protocol for the registry
service.
Gavin, at the previous GO-ESSP telco you indicated using hessian for
the
protocol. This seems like this would be a great place to use a rest
service rather than hessian. Conceptually is should be pretty simple to
do as a rest service:

* nodes post their node configuration to the service
* nodes get the registry information from the service. This could range
from a simple give me everything request to very specific queries.

Going the rest route seems like it would be much simpler from a few
aspects. No interfaces to distribute, simple API, don't necessarily
need
a client, easily accessible as no limitation on Hessian library
support,
etc...

Note: I would would like to see the Hessian APIs in the gateway
replaced
with rest based APIs as well.

It would also be really helpful if we could see the intended API for
the
client side of the registry service regardless of protocol.

Thanks!
-Nate
_______________________________________________
esg-gateway-dev mailing list
esg-gateway-dev at mailman.earthsystemgrid.org<mailto:esg-gateway-dev at mailman.earthsystemgrid.org>
http://mailman.earthsystemgrid.org/mailman/listinfo/esg-gateway-dev

Rachana Ananthakrishnan
Argonne National Lab | University of Chicago

_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

--
Gavin M. Bell
--

 "Never mistake a clear view for a short distance."
               -Paul Saffo

_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110317/cdc281bd/attachment-0001.html 