HPCBP Extensions Short-list
Hi, I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. Turns out our list is pretty short (in no particular order): File staging (already in process) Kerberos credentials (with Active Directory support) Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work) Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what's in use and what's free; maybe also leveraging the Glue Scheme) Resource usage data (for simple accounting and status reporting) Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension? Best regards, - bill Bill Nitzberg Altair PBS Gridworks
Bill Nitzberg wrote:
I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. [...] Kerberos credentials (with Active Directory support)
We've got people here in Manchester who are interested in passing about Kerberos credentials so they can access AFS from their jobs. (I don't need it for what I do, but they do.)
Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work)
As far as I know, they don't say anything much about the actual list of available applications. Or rather they do, but they don't describe any interoperable basis for actual naming of applications: the names are just arbitrary strings in the GLUE model. Without some kind of catalog of standard names, it'll be really hard to make progress on interop on the basis of GLUE here (except within restricted domains where such catalogs are unnecessary).
Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what’s in use and what’s free; maybe also leveraging the Glue Scheme)
This is strongly in the scope of GLUE; if they can't do it, they need to know soon! :-)
Resource usage data (for simple accounting and status reporting)
Sounds like you want to use/profile the Usage Record. FWIW, I've had enhanced job execution engines in the past which exposed a UR as a property of the job resource once the job completed (so that distribution of the record could be done via WS-Notification, which I had easily to hand at the time). As far as I could see, it worked quite reasonably.
Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension?
I can shove my oar in in quite a few places. :-) Donal.
Perhaps it would be worth trying to schedule a GLUE/HPCP session at OGF22 to talk about how GLUE can be used to do machine inventory and software inventory? -- Chris On 11/12/07 06:10, "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote:
Bill Nitzberg wrote:
I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. [...] Kerberos credentials (with Active Directory support)
We've got people here in Manchester who are interested in passing about Kerberos credentials so they can access AFS from their jobs. (I don't need it for what I do, but they do.)
Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work)
As far as I know, they don't say anything much about the actual list of available applications. Or rather they do, but they don't describe any interoperable basis for actual naming of applications: the names are just arbitrary strings in the GLUE model. Without some kind of catalog of standard names, it'll be really hard to make progress on interop on the basis of GLUE here (except within restricted domains where such catalogs are unnecessary).
Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what¹s in use and what¹s free; maybe also leveraging the Glue Scheme)
This is strongly in the scope of GLUE; if they can't do it, they need to know soon! :-)
Resource usage data (for simple accounting and status reporting)
Sounds like you want to use/profile the Usage Record. FWIW, I've had enhanced job execution engines in the past which exposed a UR as a property of the job resource once the job completed (so that distribution of the record could be done via WS-Notification, which I had easily to hand at the time). As far as I could see, it worked quite reasonably.
Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension?
I can shove my oar in in quite a few places. :-)
Donal. -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
On 11/12/07 06:10, "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote:
Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work)
As far as I know, they don't say anything much about the actual list of available applications. Or rather they do, but they don't describe any interoperable basis for actual naming of applications: the names are just arbitrary strings in the GLUE model. Without some kind of catalog of standard names, it'll be really hard to make progress on interop on the basis of GLUE here (except within restricted domains where such catalogs are unnecessary).
I think that doing catalogs would be very difficult, since there is such a large set of these things, and (as you say) each restricted domain has it's own notion of the catalog. I guess in my mind it comes in two parts: first is the mechanism to advertise locally available applications (queried with GetFactoryAttributes) such that I know what "strings" to put in the ApplicationName element of JSDL; second is to try to catalog a number of "standard" application names. I think the first is straightforward and easily doable and will provide lots of mileage in restricted domains, and that the second is a longer term activity that will always be updated.
Resource usage data (for simple accounting and status reporting)
Sounds like you want to use/profile the Usage Record. FWIW, I've had enhanced job execution engines in the past which exposed a UR as a property of the job resource once the job completed (so that distribution of the record could be done via WS-Notification, which I had easily to hand at the time). As far as I could see, it worked quite reasonably.
This seems worthwhile to pursue. Bill and I were also envisioning getting UR updates throughout the lifetime of the job, so that you could see the running status. This is a quite common requirement from our customers. -- Chris
Christopher Smith wrote:
I think that doing catalogs would be very difficult, since there is such a large set of these things, and (as you say) each restricted domain has it's own notion of the catalog. I guess in my mind it comes in two parts: first is the mechanism to advertise locally available applications (queried with GetFactoryAttributes) such that I know what "strings" to put in the ApplicationName element of JSDL; second is to try to catalog a number of "standard" application names. I think the first is straightforward and easily doable and will provide lots of mileage in restricted domains, and that the second is a longer term activity that will always be updated.
I think there's some things that are entirely possible to pursue, and others that are incredibly difficult. In terms of modelling, if you can stand looking at MOF files at all, do look at what CIM has to say on the topic. Although the DMTF don't do the catalog, they have identified what set of attributes actually identify a piece of software. Forcing some kind of correspondence there between CIM, GLUE, JSDL, ACS and BES would be a Very Good Thing. In terms of a catalog, things are just plain nasty. I've definitely seen several applications with the same name (not everyone goes to the effort of using trademark law to prevent clashes) and this can cause a lot of confusion. It already does. The best thing I can think of right now to work around this is for us to encourage the use of some kind of hierarchical naming model for applications; much commercial software already fits this to quite an extent due to the use of the vendor's name ("Microsoft Windows Vista", "Platform LSF") so formalizing it is unlikely to be a very hard sell. By contrast, a comprehensive catalog of everything is just plain impossible in practice. Oh, and whatever anyone else says, "a.out" is *not* a legal application name! (It's an executable name, which is something else.)
This seems worthwhile to pursue. Bill and I were also envisioning getting UR updates throughout the lifetime of the job, so that you could see the running status. This is a quite common requirement from our customers.
I'll be interested to see how you get along with this; I need to start working on doing the experiences document for UR1.0 soon. :-) Donal.
I would not disagree with this list... but I would like to see us complete some of the work we are already doing before starting something new - bandwidth is not unlimited! I would agree with Kerberos being the next 'new' thing for us. The Application & Machine inventory I hope could be done by profiling Glue and using the existing FactoryAttributes operation - if not then there is a big problem with Glue! The Resource Usage data is already quite advanced in the UR and RUS groups... though both groups go in fits and starts! Extending the HPC profile WG to cover this would be a big stretch IMHO. Better to leverage this work. Steven From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Bill Nitzberg Sent: Monday, December 10, 2007 7:41 PM To: ogsa-hpcp-wg@ogf.org Subject: [ogsa-hpcp-wg] HPCBP Extensions Short-list Hi, I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. Turns out our list is pretty short (in no particular order): File staging (already in process) Kerberos credentials (with Active Directory support) Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work) Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what's in use and what's free; maybe also leveraging the Glue Scheme) Resource usage data (for simple accounting and status reporting) Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension? Best regards, - bill Bill Nitzberg Altair PBS Gridworks
This should be an interesting phone call. Let me go through these and add comments, then a few of my own. File staging. Yes. But before we can do a good job on staging we need a solution to the delegation problem. As I said in Seattle I am unhappy with the solution of an extra parameter to the call. Can we not come up with a solution that might be useable for other services as well, e.g., somewhere in the soap header? 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? 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. Machine inventory. The BES specficiation has something for this that was the result of much discussion between GLUE folks, CIM, etc. Resource usage data! I'm all for this, can we just use RUS? A _____ From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Bill Nitzberg Sent: Monday, December 10, 2007 10:41 PM To: ogsa-hpcp-wg@ogf.org Subject: [ogsa-hpcp-wg] HPCBP Extensions Short-list Hi, I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. Turns out our list is pretty short (in no particular order): File staging (already in process) Kerberos credentials (with Active Directory support) Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work) Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what's in use and what's free; maybe also leveraging the Glue Scheme) Resource usage data (for simple accounting and status reporting) Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension? Best regards, - bill Bill Nitzberg Altair PBS Gridworks
Re: "file staging". I think the approach that multiple active participants of the group are currently pursuing (see Steven's most recent thread) is the appropriate approach, given the scope and intent of this WG. We made good progress in Supercomputing 2007 - both refining and validating the approach. I believe that this is a good plan. Phone call in 7 minutes. -- Marty From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Thursday, December 13, 2007 8:51 AM To: 'Bill Nitzberg'; ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] HPCBP Extensions Short-list This should be an interesting phone call. Let me go through these and add comments, then a few of my own. File staging. Yes. But before we can do a good job on staging we need a solution to the delegation problem. As I said in Seattle I am unhappy with the solution of an extra parameter to the call. Can we not come up with a solution that might be useable for other services as well, e.g., somewhere in the soap header? 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? 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. Machine inventory. The BES specficiation has something for this that was the result of much discussion between GLUE folks, CIM, etc. Resource usage data! I'm all for this, can we just use RUS? A _____ From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Bill Nitzberg Sent: Monday, December 10, 2007 10:41 PM To: ogsa-hpcp-wg@ogf.org Subject: [ogsa-hpcp-wg] HPCBP Extensions Short-list Hi, I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. Turns out our list is pretty short (in no particular order): File staging (already in process) Kerberos credentials (with Active Directory support) Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work) Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what's in use and what's free; maybe also leveraging the Glue Scheme) Resource usage data (for simple accounting and status reporting) Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension? Best regards, - bill Bill Nitzberg Altair PBS Gridworks
Hi, I agree with Marty's comment. (Sorry I missed the telecon, my day job got in the way; I know I still owe our experience for the experience doc). Best regards, - bill _____ From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Marty Humphrey Sent: Thursday, December 13, 2007 9:28 AM To: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] HPCBP Extensions Short-list Re: "file staging". I think the approach that multiple active participants of the group are currently pursuing (see Steven's most recent thread) is the appropriate approach, given the scope and intent of this WG. We made good progress in Supercomputing 2007 - both refining and validating the approach. I believe that this is a good plan. Phone call in 7 minutes. -- Marty From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Thursday, December 13, 2007 8:51 AM To: 'Bill Nitzberg'; ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] HPCBP Extensions Short-list This should be an interesting phone call. Let me go through these and add comments, then a few of my own. File staging. Yes. But before we can do a good job on staging we need a solution to the delegation problem. As I said in Seattle I am unhappy with the solution of an extra parameter to the call. Can we not come up with a solution that might be useable for other services as well, e.g., somewhere in the soap header? 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? 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. Machine inventory. The BES specficiation has something for this that was the result of much discussion between GLUE folks, CIM, etc. Resource usage data! I'm all for this, can we just use RUS? A _____ From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Bill Nitzberg Sent: Monday, December 10, 2007 10:41 PM To: ogsa-hpcp-wg@ogf.org Subject: [ogsa-hpcp-wg] HPCBP Extensions Short-list Hi, I had occasion to have coffee with Chris Smith today, and we discussed what we think would be the most useful near-term extensions to the HPCBP. Turns out our list is pretty short (in no particular order): File staging (already in process) Kerberos credentials (with Active Directory support) Application inventory (a simple list of available applications, maybe leveraging the Glue Scheme work) Machine inventory (a list of hardware: hosts, cpus, memory, etc, as well as what's in use and what's free; maybe also leveraging the Glue Scheme) Resource usage data (for simple accounting and status reporting) Anyone else interested in any of these areas? Anyone interested enough to work on drafting an extension? Best regards, - bill Bill Nitzberg Altair PBS Gridworks
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... ]
Donal K. Fellows wrote:
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 realize this isn't an OGF issue, but is the solution here to map from X.509 to Kerberos credentials, as we do in various Globus deployments for example? Ian.
Ian Foster wrote:
Donal K. Fellows wrote:
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 realize this isn't an OGF issue, but is the solution here to map from X.509 to Kerberos credentials, as we do in various Globus deployments for example?
I've no idea really; it's not my own area to be honest. Is there a written up way to do this somewhere that I can point my colleague at? Donal.
Ian, Donal, There are different ways of handling this depending on the OS you run. In Windows you can set up X.509 certificate mapping rules to AD accounts, either using IIS mechanisms for a particular web service or AD for domain-wide rules. Unix privileged processes can do similar mapping. There is, naturally, some admin pain in that one needs to pre-define these mapping rules. Based on prior conversations, it is my understanding that this is not the motivating scenario behind the proposed HPCP extension (We do need to write up the use case(s) before drafting the profile). If users already have X.509 credentials used to authenticate to BES services, then the existing HPCP security profile is adequate to support X.509-based mutual authentication. Hints that a BES, or compute cluster, should map to an account to execute the job or perform data staging would most naturally fit under the Activity Credential proposal. What is missing is an interop profile for how users and the BES will authenticate, and provide message integrity and confidentiality, when there is an existing Kerberos infrastructure but no deployed X.509 infrastructure. This is reasonably common for environments matching the base use case documented by the HPCP WG. Regards, Blair
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg- bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Friday, December 14, 2007 3:35 AM To: Ian Foster Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] HPCBP Extensions Short-list
Donal K. Fellows wrote:
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
to use Kerberos to authenticate to the BES instance in that case
Ian Foster wrote: them though,
mostly because our IT department only tolerates Kerberos to support AFS.
I realize this isn't an OGF issue, but is the solution here to map from X.509 to Kerberos credentials, as we do in various Globus deployments for example?
I've no idea really; it's not my own area to be honest. Is there a written up way to do this somewhere that I can point my colleague at?
Donal. -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
The work that I was thinking of is this: 1) PKINIT, for mapping from X.509 credentials to Kerberos credentials. See: http://www.globus.org/grid_software/security/pkinit.php The link there needs to be updated, I believe it should be to: http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/PKINIT.html 2) KX509 and KCA, for mapping from Kerberos credentials to X.509 credentials. (Basically a lightweight certificate authority.) See http://www.globus.org/grid_software/security/kx509-and-kca.php. Ian. Blair Dillaway wrote:
Ian, Donal,
There are different ways of handling this depending on the OS you run. In Windows you can set up X.509 certificate mapping rules to AD accounts, either using IIS mechanisms for a particular web service or AD for domain-wide rules. Unix privileged processes can do similar mapping. There is, naturally, some admin pain in that one needs to pre-define these mapping rules.
Based on prior conversations, it is my understanding that this is not the motivating scenario behind the proposed HPCP extension (We do need to write up the use case(s) before drafting the profile). If users already have X.509 credentials used to authenticate to BES services, then the existing HPCP security profile is adequate to support X.509-based mutual authentication. Hints that a BES, or compute cluster, should map to an account to execute the job or perform data staging would most naturally fit under the Activity Credential proposal.
What is missing is an interop profile for how users and the BES will authenticate, and provide message integrity and confidentiality, when there is an existing Kerberos infrastructure but no deployed X.509 infrastructure. This is reasonably common for environments matching the base use case documented by the HPCP WG.
Regards, Blair
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg- bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Friday, December 14, 2007 3:35 AM To: Ian Foster Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] HPCBP Extensions Short-list
Donal K. Fellows wrote:
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
to use Kerberos to authenticate to the BES instance in that case
Ian Foster wrote: them though,
mostly because our IT department only tolerates Kerberos to support AFS. I realize this isn't an OGF issue, but is the solution here to map from X.509 to Kerberos credentials, as we do in various Globus deployments for example? I've no idea really; it's not my own area to be honest. Is there a written up way to do this somewhere that I can point my colleague at?
Donal. -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
participants (8)
-
Andrew Grimshaw -
Bill Nitzberg -
Blair Dillaway -
Christopher Smith -
Donal K. Fellows -
Ian Foster -
Marty Humphrey -
Steven Newhouse