Hey Keisuke, thanks for your patience. I wound up getting home from work last night, sorry to have missed the meeting. Yes, I would be happy to address the below questions/comments. Sorry to not have been able to attend the last GGF. You mention that: In the section "3.1.4 Relationship between AA and Job" (Page 14), you left the comment "D10" below: Perhaps we could say a unit of "configuration management" We didn't see problem here in the review at GGF15. Can you elaborate on this a bit more? I think the above statement did not outline a problem in the doc that needed fixing, but rather an opportunity to make the distinction between sofware components, configuration and runtime parameters/contraints[jsdl], and that these distinct components could be concidered one configuration mananaged package within the AA. (a managed unit w/ version) This is important for automated repeatability. This relates to some comments that Andrew Grimshaw had at the Sunnyvale face to face, that one can take a software unit, supply different parameters, and in essence wind up with a "new piece of software and function". At the time, to me it seemed important to capture a version and place for this new piece of software. So by treating job as part of AA content, this is possible. In this way, to run a job, one could pass to the "job manager" the EPR to an AA. I am not sure I can defend myself properly on this position, it seems on the surface plausible, but not mandetory. It seems more highly organized than having the JDSL somewhere out there, but also the idea seems to not be required in all use cases. Hope this helps to clarify :-) With respect to replication, what is written in 4.5 is fine. I think we should perhaps leave things to master/slave for now to be able to accomplish a version 1.0. My comments a few meetings ago about replication GUIDs are really only a concern in bi-direction replication, so we are ok for now. There are too many open GGF issues right now with repect to naming, which would be a key component of any replication scheme, and also, the orep-wg's inactivity (last time a looked [a few months ago]). I think what is written is excellent for now. Pete -----Original Message----- From: Keisuke Fukui [mailto:kfukui@labs.fujitsu.com] Sent: Thursday, October 13, 2005 4:12 AM To: Ziu, Peter Cc: acs-wg@ggf.org Subject: Your comments on the draft spec. Hello Pete, How is it going? We hope that we finish the version 1.0 in this month to make us released for the further step toward 2.0 and EMS discussions. So here are something for you to make it happen:-) I need clarifications for some of your comments seen in the draft 0.51 that we have reviewed at GGF15 sessions. --------------------------------------------------------------- In the section "3.1.4 Relationship between AA and Job" (Page 14), you left the comment "D10" below: Perhaps we could say a unit of "configuration management" We didn't see problem here in the review at GGF15. Can you elaborate on this a bit more? --------------------------------------------------------------- Is the current description for section "4.5 replication" good to you? If you have more to add, please let us review and merge it to the current one. --------------------------------------------------------------- I will appreciate it very much if you briefly address to the above here. I'm sorry for bothering you this time. Thanks in advance!! -Keisuke
Pete, Glad to hear that you doing fine and hope to see you. I will prepare myself for the discussion toward next step. Ziu, Peter wrote:
In the section "3.1.4 Relationship between AA and Job" (Page 14), you left the comment "D10" below: Perhaps we could say a unit of "configuration management"
We didn't see problem here in the review at GGF15. Can you elaborate on this a bit more?
I think the above statement did not outline a problem in the doc that needed fixing, but rather an opportunity to make the distinction between sofware components, configuration and runtime parameters/contraints[jsdl], and that these distinct components could be concidered one configuration mananaged package within the AA.
I come to understand a part of your point in the original description: ---------------------------------------------------------------------------- An AA can be used to create a job, i.e. a unit of task, in the grid system. ---------------------------------------------------------------------------- However, we have a general description of AA, a few pages before, in section "3.1.1 Application Archive and Repository" as below: ---------------------------------------------------------------------------- Such information may include, but not limited to, the application executable code, configuration data necessary for initial deployment of the application and the deployment descriptor documents. ---------------------------------------------------------------------------- This clearly states that not only the software components, but also any data specific to the software can be stored. Then, we came here to in "3.1.4 Relationship between AA and Job", drilling down to the advanced topic. As such, the description here is focusing the relationship to Job instance of AA instance. An single AA should be able to be reused to instantiate multiple jobs. So the relationship between them should be maintained by Job Managing entity in the system. I explained this in the slides named "acs_GGF15-F2F-EMS-draft.ppt" attached to my message in ogsa-wg ML on Oct 12 in response to Dejan of CDDLM. It would be better if we could have simple and complete statement in one place. I think the current text is my best shot, though I admit they may give the readers somewhat dispersed and complex impression. In summary, I believe that the original text doesn't conflict your vision. Please correct me if I'm still besides the point.
package within the AA. (a managed unit w/ version) This is important for automated repeatability. This relates to some comments that Andrew Grimshaw had at the Sunnyvale face to face, that one can take a software unit, supply different parameters, and in essence wind up with a "new piece of software and function". At the time, to me it seemed important to capture a version and place for this new piece of software. So by treating job as part of AA content, this is possible. In this way, to run a job, one could pass to the "job manager" the EPR to an AA. I am not sure I can defend myself properly on this position, it seems on the surface plausible, but not mandetory. It seems more highly organized than having the JDSL somewhere out there, but also the idea seems to not be required in all use cases. Hope this helps to clarify :-)
With respect to replication, what is written in 4.5 is fine. I think we should perhaps leave things to master/slave for now to be able to accomplish a version 1.0. My comments a few meetings ago about replication GUIDs are really only a concern in bi-direction replication, so we are ok for now. There are too many open GGF issues right now with repect to naming, which would be a key component of any replication scheme, and also, the orep-wg's inactivity (last time a looked [a few months ago]). I think what is written is excellent for now.
Thanks! I've been trying to keep our first specification simple, as well as very combinable with other specifications or technologies, to go along with SOA thought. Those replication topics are among them in my mind. ACS should be a pluggable service component in the grid systems. I hope once we finish the base spec out, then we can continue building another one on top of that. -Keisuke
participants (2)
-
Keisuke Fukui
-
Ziu, Peter