[ogsa-hpcp-wg] HPCBP Extensions Short-list

[Donal K. Fellows]

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... ]