[gin-info] Possible list of subset data for info interop

[JP Navarro]

On Mar 2, 2006, at 9:35 AM, Laurence Field wrote:

> service type     (example "prews-gram-pbs")
> service version  (example "4.0.1")
> service host     (example "tg-grid1.uc.teragrid.org")
> service port     (example "2119")
> service path     (example "/jobmanager-pbs")
> * path would be a URL path in the case of web services)
>
> This is prety much the same as using ServiceType and ServiceEnd  
> point.  The version tag is debatable. Should you not get this by  
> contacting the endpoint?

Yes, host, port, and path could be collapsed into a single ServiceEnd  
point
attribute, or left separate since they are distinct sub-attribures.

Not all services can be queried for version and it shouldn't be  
difficult to
publish it with other service attributes. The version is an important  
attribute
when choosing a service.  We have both GT 2.4.3 PBS Gram and GT 4.0.1  
pre-WS PBS
Gram available. Tools should be able to query the information service  
and see
that there are mutiple Gram services of possibly different versions.

> package name
> package version
> package description
>
> It is diffcult to publish every package installed.  We can group  
> packages togther and publish a RunTimeEnvironment, this could  
> require a version. I don't think a description is required. We just  
> need the tag to match on. If we  need want to know what this  
> RunTimeEnvironment is, google :)

I don't know anything about RunTimeEnvironment. Did a quick google  
and some
clicking and it looks like Microsoft support it.

The TeraGrid has per site catalogs of deployed software. We  
synchronize between
sites catalog contents for common software so users have a consistent  
handles.

For example, all TeraGrid resources are deploying:

package name = globus
package version = 4.0.1
package release = r3
package description = Complete Globus 4.0.1 client and libraries

Individual TeraGrid sites can add site local software to their catalogs.

We would like to publish the above attributes for all our packages thru
an information service.

> outage start datetime
> outage end datetime
> outage summary
> outage affected components description
>
>
> These are operations parameters and not needed for job submission.  
> We just need to know if the service is working or not.  
> ServiceStatus should be fine.

Yeah, that a better idea.  Each service has this ServiceStatus  
attribute?

JP