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

[philip.kershaw at stfc.ac.uk]

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>
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
>> 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
>http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

-- 
Scanned by iCritical.