Folks, here's a list of issues. It's huge in numbers, but most of it is (IMHO) quite quickly fixable. 1) Fig. 1 revision 2) Fig. 2 revision 3) Prefixes and namespaces (check and update) 4) Namespace should be in the table (and update) 5) Section 3 (spec doc) general revision and polishing up 6) Update explanation for jsdl:other usage 7) Possibly reformat ch. 4.2.1 8) JSDL compliance levels How much of jsdl a system must support, not just process. Probably a topic for later. 9) The statement "If not supported then the consuming system MUST reject the document." needs a bit more explanation or re-write. 10) When/why did HostName change from 0-1 to 0-n? (reverted) 11) Filesystem name and type and filesystem reference in DataStaging 12) Mountpoint environment variable. Is the current approach ok, or should we provide a separate mechanism, e.g, a tag that if present provides the name of the environment variable in which the MountPoint value must be present. 13) Should FileSystemID be changed (back) to FileSystemName. 14) DRMAA use case for defining filenames. We have to at least be able to show an example of how to define and stage out an <Output> file. 15) CreationFlag. Was this made optional or not? Confirm and delete comment. 16) Process Topology needs review. In particular are the examples ok or not, are the definition correct and so on. Delete the yellow comments once that is done. Not sure if we should define the precise allocation behaviour or allow for that to be defined instead. 17) Section "Extending JSDL" needs an owner. I expect this section to be about 1 page long so should not be too much trouble. 18) Normative Extension is out of place 19) re-check terminology for process topology and delete comments 20) "Bytes (octets of bits)" 21) Memory limit incomplete text 22) pipe size limit incomplete text 23) Update of security considerations in line with latest decisions (when we actually reach firm decision) 24) Complete author information (see my entry as reference) 25) Update contributors and acknowledgements 26) Complete list of Normative references, e.g., CIM is still missing. 27) Glossary owner 28) Translation tables need to be added Proposal: Karl for Globus/GRAM, Chris for LSF, Saga-san for Naregi, ??? for Condor, ... 28a) Put the translation tables into a separate document? 29) Promised examples for the appendix (But maybe this should be split off into a Primer) 30) Make citations in text of document reference real cross-references. 31) Complete example sub-sections --- For those that read until here: Is anything missing? Cheers, Michel
On Apr 12, Michel Drescher loaded a tape reading: ...
10) When/why did HostName change from 0-1 to 0-n? (reverted)
At GGF-13 and who keeps trying to set it back to 1? :-) It is 0-n to allow for resource selection of nodes in a parallel job. Chris Smith has that use case with LSF and I can endorse it as a useful thing for parallel jobs too (whether it is in GRAM today or not!). This goes hand-in-hand with the notion of there being a count for the resource element, meaning multiple resources must be allocated to match the same element. The semantics is each resource MUST have one of the names in the list. In other words, if there are more hostnames listed than resources requested, not all names are utilized, or the match predicate for a host is membership of that host's name in the list. karl -- Karl Czajkowski karlcz@univa.com
Karl Czajkowski wrote:
On Apr 12, Michel Drescher loaded a tape reading: ...
10) When/why did HostName change from 0-1 to 0-n? (reverted)
At GGF-13 and who keeps trying to set it back to 1? :-)
Guilty as charged. It must have been in the last session that I missed. I am working on releasing the next version of the spec. and it is inconsistent in the definition of this element (some places * and some ?). It was not clear which way was intended or why, hence the comment.
It is 0-n to allow for resource selection of nodes in a parallel job. Chris Smith has that use case with LSF and I can endorse it as a useful thing for parallel jobs too (whether it is in GRAM today or not!). This goes hand-in-hand with the notion of there being a count for the resource element, meaning multiple resources must be allocated to match the same element. The semantics is each resource MUST have one of the names in the list. In other words, if there are more hostnames listed than resources requested, not all names are utilized, or the match predicate for a host is membership of that host's name in the list.
Thanks for the explanation, Karl. I'll have to think about it tomorrow after I get some sleep. (Everything looks better in sunlight. :-) Andreas
I have a followup question on changing the hostname from 0-1 to 0-n. In the spec we had said that hostname may refer to a single host or any logical group of hosts. (And that logical group could be anything understood by the system.) The intention was to be able to do something like <Resource> <HostName> the-nine-muses </HostName> ... <ResourceCount> <exact>2.0<exact></ResourceCount> </Resource> And get back, for example, resources "thalia" and "urania". Doesn't this cover already (most of) the use case mentioned below and is there really a need to change the multiplicity of this element. Andreas Andreas Savva wrote:
Karl Czajkowski wrote:
On Apr 12, Michel Drescher loaded a tape reading: ...
10) When/why did HostName change from 0-1 to 0-n? (reverted)
At GGF-13 and who keeps trying to set it back to 1? :-)
Guilty as charged. It must have been in the last session that I missed.
I am working on releasing the next version of the spec. and it is inconsistent in the definition of this element (some places * and some ?). It was not clear which way was intended or why, hence the comment.
It is 0-n to allow for resource selection of nodes in a parallel job. Chris Smith has that use case with LSF and I can endorse it as a useful thing for parallel jobs too (whether it is in GRAM today or not!). This goes hand-in-hand with the notion of there being a count for the resource element, meaning multiple resources must be allocated to match the same element. The semantics is each resource MUST have one of the names in the list. In other words, if there are more hostnames listed than resources requested, not all names are utilized, or the match predicate for a host is membership of that host's name in the list.
Thanks for the explanation, Karl. I'll have to think about it tomorrow after I get some sleep. (Everything looks better in sunlight. :-)
Andreas
On Apr 14, Andreas Savva loaded a tape reading:
I have a followup question on changing the hostname from 0-1 to 0-n. In the spec we had said that hostname may refer to a single host or any logical group of hosts. (And that logical group could be anything understood by the system.) The intention was to be able to do something like <Resource> <HostName> the-nine-muses </HostName> ... <ResourceCount> <exact>2.0<exact></ResourceCount> </Resource>
And get back, for example, resources "thalia" and "urania".
Doesn't this cover already (most of) the use case mentioned below and is there really a need to change the multiplicity of this element.
Andreas
A common real-world example is that I am choosing from a set of nodes in a cluster according to an arbitrary application-specific constraint that cannot be captured in the resource selection language otherwise. I've seen this with some stateful "storage" clusters where one job wrote data to a set of nodes and subsequent jobs need to process them. It is ugly but useful. In GRAM we have seen sites add site-specific extensions to handle this since we did not provide it in our RSL. karl -- Karl Czajkowski karlcz@univa.com
My concern here isn't so much that enumerating a set of hostnames and choosing N of them isn't useful. It is rather that this is a case of an implicit choice rule different from our default "satisfy all" rule. In giving the example below, I was trying to suggest that we did support part of the use case and could perhaps claim that the rest can be satisfied when composing jsdl with some other operator language. If the consensus is that having a small number of instances of this rule (I can think of another place where we have a variant) is a good thing then I might go along with it. But I feel it is clearer (though perhaps inconvenient) not to have such exceptions. Let's chat about this tonight (over Champagne as Ali suggested :-) Andreas Karl Czajkowski wrote:
On Apr 14, Andreas Savva loaded a tape reading:
I have a followup question on changing the hostname from 0-1 to 0-n. In the spec we had said that hostname may refer to a single host or any logical group of hosts. (And that logical group could be anything understood by the system.) The intention was to be able to do something like <Resource> <HostName> the-nine-muses </HostName> ... <ResourceCount> <exact>2.0<exact></ResourceCount> </Resource>
And get back, for example, resources "thalia" and "urania".
Doesn't this cover already (most of) the use case mentioned below and is there really a need to change the multiplicity of this element.
Andreas
A common real-world example is that I am choosing from a set of nodes in a cluster according to an arbitrary application-specific constraint that cannot be captured in the resource selection language otherwise.
I've seen this with some stateful "storage" clusters where one job wrote data to a set of nodes and subsequent jobs need to process them. It is ugly but useful. In GRAM we have seen sites add site-specific extensions to handle this since we did not provide it in our RSL.
karl
-- Andreas Savva Fujitsu Laboratories Ltd
Andreas Savva wrote:
My concern here isn't so much that enumerating a set of hostnames and choosing N of them isn't useful. It is rather that this is a case of an implicit choice rule different from our default "satisfy all" rule.
In giving the example below, I was trying to suggest that we did support part of the use case and could perhaps claim that the rest can be satisfied when composing jsdl with some other operator language.
If the consensus is that having a small number of instances of this rule (I can think of another place where we have a variant) is a good thing then I might go along with it. But I feel it is clearer (though perhaps inconvenient) not to have such exceptions.
My inclination is to think of the resource satisfaction rule as being that "all the requested resources must be available/allocated". That does not say that the job has to actually use them all, but it does define the space within which the job can rattle around. If a hostname identifies a set of machines in some sense, then it can be taken as referring to an arbitrary subset of those machines (as constrained by the other terms and any policies enforced) but that's simply because we're not defining what it means to claim the resource that is an externally-defined set of machines. Anything more complex than "claim all the resources" requires some kind of resource selection and preferencing (?) language, and is thankfully out of our scope. :-) Donal.
Many thanks for this Michel. There is a missing issue. Fairly high up on the list should be the issue about what to do with the User and Group ID info/elements? We've carried this issue over from the previous discussion and discussed it at length on the list. We just need to finalise our decision and move on. Summary of my observation is that: POSIX User and Group ID elements are required in the POSIX Application section/element only for now. We can extend this for further application types (e.g. Web Service invocation) by adding new, more specific, user ID elements. Other ideas are: 1. Different user types in a User element, which can be added to later: <User> <POSIXUser/> <POSIXGroup/> <WebServiceUser/> <OracleUser/> <XindeceUser/> </User> 2. General UID and GID with extensibility: <User> <UID/> <GID/> <xsd:any##other> </User> I'm in favour of 1. if we're to have a dedicated User element - i.e. not application specific like: <Application type="POSIX"> <UID/> <GID/> </Application> as suggested in the opening paragraph. Cheers and take care, Ali On Tue, 12 Apr 2005, Michel Drescher wrote:
Folks,
here's a list of issues. It's huge in numbers, but most of it is (IMHO) quite quickly fixable.
1) Fig. 1 revision
2) Fig. 2 revision
3) Prefixes and namespaces (check and update)
4) Namespace should be in the table (and update)
5) Section 3 (spec doc) general revision and polishing up
6) Update explanation for jsdl:other usage
7) Possibly reformat ch. 4.2.1
8) JSDL compliance levels How much of jsdl a system must support, not just process. Probably a topic for later.
9) The statement "If not supported then the consuming system MUST reject the document." needs a bit more explanation or re-write.
10) When/why did HostName change from 0-1 to 0-n? (reverted)
11) Filesystem name and type and filesystem reference in DataStaging
12) Mountpoint environment variable. Is the current approach ok, or should we provide a separate mechanism, e.g, a tag that if present provides the name of the environment variable in which the MountPoint value must be present.
13) Should FileSystemID be changed (back) to FileSystemName.
14) DRMAA use case for defining filenames. We have to at least be able to show an example of how to define and stage out an <Output> file.
15) CreationFlag. Was this made optional or not? Confirm and delete comment.
16) Process Topology needs review. In particular are the examples ok or not, are the definition correct and so on. Delete the yellow comments once that is done. Not sure if we should define the precise allocation behaviour or allow for that to be defined instead.
17) Section "Extending JSDL" needs an owner. I expect this section to be about 1 page long so should not be too much trouble.
18) Normative Extension is out of place
19) re-check terminology for process topology and delete comments
20) "Bytes (octets of bits)"
21) Memory limit incomplete text
22) pipe size limit incomplete text
23) Update of security considerations in line with latest decisions (when we actually reach firm decision)
24) Complete author information (see my entry as reference)
25) Update contributors and acknowledgements
26) Complete list of Normative references, e.g., CIM is still missing.
27) Glossary owner
28) Translation tables need to be added Proposal: Karl for Globus/GRAM, Chris for LSF, Saga-san for Naregi, ??? for Condor, ... 28a) Put the translation tables into a separate document?
29) Promised examples for the appendix (But maybe this should be split off into a Primer)
30) Make citations in text of document reference real cross-references.
31) Complete example sub-sections
---
For those that read until here: Is anything missing?
Cheers, Michel
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
Ali: I am partial to the opening idea, e.g. that the posix application element get its own user and group IDs that _only_ mean the user/group settings for the execution. I wouldn't want to see them get mixed up in more traditional notions of user, e.g. the user or "account" to which the job charges are accounted. Even though these will sometimes (often?) be the same string, that doesn't mean they are the same concept. I think it is better to organize the support for concepts based on how they are related to one another in use, e.g. the posix set of parameters are separated from the resource selection criteria, rather than to how they might appear similar through the haze of abstraction. I guess I am realizing that the User section bothers me because it is trying to be a "stovepipe" abstraction among a set of more horizontal "layers" like resource selection and job configuration. I think better layers to go with these would be "authentication and authorization tokens, assertions, etc." and "accounting". Each of these may have some aspect of "userness" in them. :-/ karl On Apr 12, Ali Anjomshoaa loaded a tape reading:
Many thanks for this Michel. There is a missing issue. Fairly high up on the list should be the issue about what to do with the User and Group ID info/elements? We've carried this issue over from the previous discussion and discussed it at length on the list. We just need to finalise our decision and move on.
Summary of my observation is that:
POSIX User and Group ID elements are required in the POSIX Application section/element only for now. We can extend this for further application types (e.g. Web Service invocation) by adding new, more specific, user ID elements.
Other ideas are:
1. Different user types in a User element, which can be added to later:
<User> <POSIXUser/> <POSIXGroup/> <WebServiceUser/> <OracleUser/> <XindeceUser/> </User>
...
I'm in favour of 1. if we're to have a dedicated User element - i.e. not application specific like:
<Application type="POSIX"> <UID/> <GID/> </Application>
as suggested in the opening paragraph.
Cheers and take care,
Ali
-- Karl Czajkowski karlcz@univa.com
Hi Karl and others, On 12 Apr 2005, at 14:00, Karl Czajkowski wrote:
Ali: I am partial to the opening idea, e.g. that the posix application element get its own user and group IDs that _only_ mean the user/group settings for the execution. I wouldn't want to see them get mixed up in more traditional notions of user, e.g. the user or "account" to which the job charges are accounted.
Yes, add me to the supporters of that idea.
Even though these will sometimes (often?) be the same string, that doesn't mean they are the same concept. I think it is better to organize the support for concepts based on how they are related to one another in use, e.g. the posix set of parameters are separated from the resource selection criteria, rather than to how they might appear similar through the haze of abstraction.
And again, I second that.
I guess I am realizing that the User section bothers me because it is trying to be a "stovepipe" abstraction among a set of more horizontal "layers" like resource selection and job configuration. I think better layers to go with these would be "authentication and authorization tokens, assertions, etc." and "accounting". Each of these may have some aspect of "userness" in them. :-/
I remember somebody (unfortunately, I forgot who it was) stating that XML is _NOT_ object oriented, and trying to apply OO based patterns to XML will bitterly fail. I think this is a classic example. (And I explicitly do not exclude myself from making that error over and over again.) Cheers, Michel
Karl Czajkowski wrote:
Ali: I am partial to the opening idea, e.g. that the posix application element get its own user and group IDs that _only_ mean the user/group settings for the execution. I wouldn't want to see them get mixed up in more traditional notions of user, e.g. the user or "account" to which the job charges are accounted.
I also feel that the notion of "who pays for the job" is unrelated (or at least sufficiently so to be outside our scope). At the very least, we can ignore such stuff for 1.0 :-) (Our main use-cases link that notion of accounting more with the notions of VOs, but we know we need more work in this area.)
Even though these will sometimes (often?) be the same string, that doesn't mean they are the same concept. I think it is better to organize the support for concepts based on how they are related to one another in use, e.g. the posix set of parameters are separated from the resource selection criteria, rather than to how they might appear similar through the haze of abstraction.
I feel that user/group is for specifying the ids in the *rare* cases when a job absolutely must run as a particular target system identity. The rest of the time, it's either stated through some other elements that we're saying nothing about, or implicit in the job submission context in some way and that'll be the right thing (and out of our scope, hooray!)
I guess I am realizing that the User section bothers me because it is trying to be a "stovepipe" abstraction among a set of more horizontal "layers" like resource selection and job configuration. I think better layers to go with these would be "authentication and authorization tokens, assertions, etc." and "accounting". Each of these may have some aspect of "userness" in them. :-/
The only concern about having the values inside the PosixApplication element type (or whatever the current name is) is how to ensure that the inward data-transfers ensure that they pick up the correct ownership information. I don't think we express the notion of whether a job wants to write to a staged-in file or not, which means we have to assume that it might... :-/ Donal.
Yes, staging is an interesting problem. One approach would be to have read/write/execute rights (implied or indicated) for stage-in files and leave it to the consumer to know if posix identity of the job process is important to implement these rights. For GRAM, we perform the staging "as" the target execution user, so we'd be covered with the current proposal, I think... :-) karl On Apr 12, Donal K. Fellows loaded a tape reading: ...
The only concern about having the values inside the PosixApplication element type (or whatever the current name is) is how to ensure that the inward data-transfers ensure that they pick up the correct ownership information. I don't think we express the notion of whether a job wants to write to a staged-in file or not, which means we have to assume that it might... :-/
Donal.
-- Karl Czajkowski karlcz@univa.com
Did I mess up the meeting today for the web or is the phone messed up? Darren -----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Karl Czajkowski Sent: Tuesday, April 12, 2005 7:45 AM To: Donal K. Fellows Cc: JSDL WG Subject: Re: [jsdl-wg] Issues for todays phone conference Yes, staging is an interesting problem. One approach would be to have read/write/execute rights (implied or indicated) for stage-in files and leave it to the consumer to know if posix identity of the job process is important to implement these rights. For GRAM, we perform the staging "as" the target execution user, so we'd be covered with the current proposal, I think... :-) karl On Apr 12, Donal K. Fellows loaded a tape reading: ...
The only concern about having the values inside the PosixApplication element type (or whatever the current name is) is how to ensure that the inward data-transfers ensure that they pick up the correct ownership information. I don't think we express the notion of whether a job wants to write to a staged-in file or not, which means we have to assume that it might... :-/
Donal.
-- Karl Czajkowski karlcz@univa.com
Stupid Daylight savings time or something like that. The meeting looks like it was set for Standard Time not Daylight savings. I will ask Bill to fix it for next week. Darren -----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Michel Drescher Sent: Tuesday, April 12, 2005 8:11 AM To: Donal K. Fellows Cc: Darren Pulsipher; 'JSDL WG' Subject: Re: [jsdl-wg] Issues for todays phone conference Can't join the phone conference either... :-/ Michel On 12 Apr 2005, at 15:05, Donal K. Fellows wrote:
Darren Pulsipher wrote:
Did I mess up the meeting today for the web or is the phone messed up?
At least it's not just me... :^/
Donal.
Gang, can we re-schedule for this time tomorrow? 15:00 BST, 08:00 MST? Darren? Ali On Tue, 12 Apr 2005, Michel Drescher wrote:
Can't join the phone conference either... :-/
Michel
On 12 Apr 2005, at 15:05, Donal K. Fellows wrote:
Darren Pulsipher wrote:
Did I mess up the meeting today for the web or is the phone messed up?
At least it's not just me... :^/
Donal.
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
It should be 0800 MDT So what is that in GMT and then we can make sure we are talking about the same thing. -----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Ali Anjomshoaa Sent: Tuesday, April 12, 2005 8:15 AM To: Michel Drescher Cc: Donal K. Fellows; Darren Pulsipher; 'JSDL WG' Subject: Re: [jsdl-wg] Issues for todays phone conference Gang, can we re-schedule for this time tomorrow? 15:00 BST, 08:00 MST? Darren? Ali On Tue, 12 Apr 2005, Michel Drescher wrote:
Can't join the phone conference either... :-/
Michel
On 12 Apr 2005, at 15:05, Donal K. Fellows wrote:
Darren Pulsipher wrote:
Did I mess up the meeting today for the web or is the phone messed up?
At least it's not just me... :^/
Donal.
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
All, there is _very_ useful website for this: http://www.timeanddate.com (and not www.dateandtime.com *g*) that calculates dates and times for you. So, 0800 MDT is: http://www.timeanddate.com/worldclock/fixedtime.html? year=2005&month=4&day=13&hour=14&min=0&sec=0 or http://tinyurl.com/4g65x From now on, there are no excuses anymore. :-) Cheers, Michel On 12 Apr 2005, at 15:17, Darren Pulsipher wrote:
It should be 0800 MDT
So what is that in GMT and then we can make sure we are talking about the same thing.
-----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Ali Anjomshoaa Sent: Tuesday, April 12, 2005 8:15 AM To: Michel Drescher Cc: Donal K. Fellows; Darren Pulsipher; 'JSDL WG' Subject: Re: [jsdl-wg] Issues for todays phone conference
Gang,
can we re-schedule for this time tomorrow? 15:00 BST, 08:00 MST? Darren?
Ali
On Tue, 12 Apr 2005, Michel Drescher wrote:
Can't join the phone conference either... :-/
Michel
On 12 Apr 2005, at 15:05, Donal K. Fellows wrote:
Darren Pulsipher wrote:
Did I mess up the meeting today for the web or is the phone messed up?
At least it's not just me... :^/
Donal.
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
It's telling me the meeting is over! Did I miss it? steve.. Darren Pulsipher wrote:
Did I mess up the meeting today for the web or is the phone messed up?
Darren
-----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Karl Czajkowski Sent: Tuesday, April 12, 2005 7:45 AM To: Donal K. Fellows Cc: JSDL WG Subject: Re: [jsdl-wg] Issues for todays phone conference
Yes, staging is an interesting problem. One approach would be to have read/write/execute rights (implied or indicated) for stage-in files and leave it to the consumer to know if posix identity of the job process is important to implement these rights.
For GRAM, we perform the staging "as" the target execution user, so we'd be covered with the current proposal, I think... :-)
karl
On Apr 12, Donal K. Fellows loaded a tape reading: ...
The only concern about having the values inside the PosixApplication element type (or whatever the current name is) is how to ensure that the inward data-transfers ensure that they pick up the correct ownership information. I don't think we express the notion of whether a job wants to write to a staged-in file or not, which means we have to assume that it might... :-/
Donal.
-- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------
I'm having the same problem. The meeting is supposed to be now. I don't know what's happened. We had the meeting at this time last week. Ali On Tue, 12 Apr 2005, Andrew Stephen McGough wrote:
It's telling me the meeting is over!
Did I miss it?
steve..
Darren Pulsipher wrote:
Did I mess up the meeting today for the web or is the phone messed up?
Darren
-----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Karl Czajkowski Sent: Tuesday, April 12, 2005 7:45 AM To: Donal K. Fellows Cc: JSDL WG Subject: Re: [jsdl-wg] Issues for todays phone conference
Yes, staging is an interesting problem. One approach would be to have read/write/execute rights (implied or indicated) for stage-in files and leave it to the consumer to know if posix identity of the job process is important to implement these rights.
For GRAM, we perform the staging "as" the target execution user, so we'd be covered with the current proposal, I think... :-)
karl
On Apr 12, Donal K. Fellows loaded a tape reading: ...
The only concern about having the values inside the PosixApplication element type (or whatever the current name is) is how to ensure that the inward data-transfers ensure that they pick up the correct ownership information. I don't think we express the notion of whether a job wants to write to a staged-in file or not, which means we have to assume that it might... :-/
Donal.
-- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
participants (7)
-
Ali Anjomshoaa -
Andreas Savva -
Andrew Stephen McGough -
Darren Pulsipher -
Donal K. Fellows -
Karl Czajkowski -
Michel Drescher