Andrew Grimshaw wrote:
Kerberos credentials. See my comment above. Or possibly I don’t know what in this case is meant by Kerberos credentials? For what? Presumably for the activity to execute with those credentials. Then why just Kerberos?
We (well, actually one of my colleagues who handles interfacing with our astrophysics and astronomy users) want it for AFS access so that we can access users' home directories. I'm less keen on having to require them to use Kerberos to authenticate to the BES instance in that case though, mostly because our IT department only tolerates Kerberos to support AFS. I hate the politics of it all. OGF's much more civilized.
Application inventory. An interesting idea, maybe just need to define a set of qnames. Let me suggest an alternative that we have developed and have working here at UVA. An application description and deployment service that is far far simpler than CDDLM. (Works with zip files) Handles 98% of the HTC usecases we have encountered very easily – and offers the ability to define an application as the application and a set of data files … meaning they don’t get copied every time.
I'm personally uninterested in deployment right now, mostly because I'm working with apps where the licensing conditions in practice preclude doing anything so fancy. (YMMV, of course.) But publishing a list of what is there, that's interesting. (Deploying an app package into a container ought to update that list, of course.) Leveraging CIM here would be A Very Good Thing, especially as they already have an application package model. That'd make it even possible to consider tying the installation of the application to the publication of the description of it in the information system. (Or maybe pulling the list of installed packages from a CIM info provider, or ...) But I'm not sure what information (other than name and version) would be usefully published. OTOH, that's enough to use with JSDL...
Resource usage data! I’m all for this, can we just use RUS?
The RUS1 specification probably isn't usable for anything practical; I've been told by multiple people that it has significant Issues when used for anything other than the most trivial things. RUS2 should be much better (since they've started with some good use cases) but I don't know what their document schedule is. On the other hand, for the cases which I think people are looking at here, the Usage Record format (which all RUS versions consume) will do for the data description schema. Using it (or maybe a profile of it[*]) is practical now, and would not preclude getting some version of RUS into the overall system later on. Donal. [* I'm not at all convinced that everything in it is suitable for use, and I think the UR1 schema's baroque, or maybe rococo... ]