Hi Stephen, On 08/09/14 17:36, stephen.burke@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
As I said, my vote would be for a "Profile" attribute, but I would like it to combined the EGI ProfileName and ProfileVersion into a single attribute. One way of doing this would be to combine the two values with a dash (e.g., OtherInfo: ProfileName=EGI, OtherInfo: ProfileVersion=1.0 becomes Profile=EGI-1.0).
In general we try to avoid having multiple pieces of formatted information in a single attribute - the main case so far is InterfaceExtension where we have yet to find a way to define or use it!
It kinda depends whether or not you consider "EGI-1.0" a formatted piece of information; it could be an opaque identifier, like "NorduNET" in my examples.
Also I'm doubtful if it means anything to support multiple profiles given that in general they will have conflicts.
Yes, that could be a problem; but it could also be that XSEDE, EGI, OSG (three names chosen at random) could have sufficiently large overlap in their profiles that a service could publish information that is good for all three profiles. AFAIK, currently there is only the EGI profile, so we're speculating here.
You could perhaps have a ProfileExtension attribute ...
What semantics would that have? [...]
True: requiring clock synchronisation isn't great. Also, it seems nobody is really using the Downtime* attributes; at least, not when I checked (perhaps nobody was in down-time just then!).
In EGI the current situation is that downtimes are managed by the GOC DB - but of course that has now adopted GLUE 2 as an information model so it would be good to bring things in line, whatever we do in the BDII. As things stand there is no easy way to import GOC DB information into the BDII information providers - potentially you could have some kind of unified interface but it seems unlikely that it will happen in practice (the work on the LCG registry was terminated due to lack of interest).
Could GOCDB itself inject the information? That would need the concept of an info-modifier: an info-provider that modifies information published by some other info-provider. That concept would be useful elsewhere; e.g., UserDomain and VOMS servers.
In any case the situation with the cloud may be different - managing downtimes for transient services via the GOC DB, which requires static registration, may not be possible. On the other hand, do transient services even have a concept of downtime?
Who can say? But I think "transient" is in the eye of the beholder: with cloud, services could be up for months, if not years. Or the downtime could be that of the cloud-provider itself, much like a CE registering downtime for an upgrade. HTH, Paul.