- acs-wg - lists.ogf.org

[ogsa-d-wg] OGSA-D-WG description for ACS specification:
by Michael Behrens 20 Oct '05

20 Oct '05

This is being posted to the ACS and OGSA-D group for inter-group communication purposes. ACS needs to be aware of data services as they will impact the ACS specification at some point in time. The ACS specification has a non-normative section for describing relationships with other groups/activities. This is the proposed paragraph for your review - what do you think? "The OGSA Data Working Group defines the data services which provide for distribution of data on the grid. ACS can utilize protocols being specified such as Byte-IO, GridFTP, and possibly Replication. ACS provides an extension point for protocols which allow implementations to specify which protocols are supported. The ACS team has reviewed their briefings and draft documents with interest. Interaction with the OGSA Data Working group is expected to increase during the development of the next version of this specification." -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)

3 6

New description for section 7.4
by Keisuke Fukui 19 Oct '05

19 Oct '05

FYI, As discussed in the last meeting, I am sending the missing description for section 7.4 Signature. Please take a look at it to review this in the meeting tomorrow. Thanks in advance. -Keisuke

1 0

Teleconference minutes - Oct 12
by Sachiko Wada 17 Oct '05

17 Oct '05

Hi team, Here is the minutes of the last teleconf. Please review it and point out where the record is not correct, if any. It is also available at Gridforge: https://forge.gridforum.org/projects/acs-wg/document/minutes-20051012/en/1 Sachiko ======================================================================= ACS Teleconference ----------------------------------------------------------------------- Date and Time: Oct 12 20:10-21:50 EDT 2005 / Oct 13 9:10-10:50 JST, 2005 Participants: Keisuke Fukui (Fujitsu) Peter Ziu (Northrop) - regrets Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes ------------------------------------------------------------------------ * Review of the proposed contents for section "3.3 Relationship to other activities". 3.3.1 OASIS SDD TC - Tom 3.3.4 OGSA Data WG - Mike, Pete 3.3.5 OASIS WSDM TC - Tom Action: Keisuke, to ask Tom to post the drafts in this week. (Done Oct 12) Action: Mike, to write draft for section 3.3.4 and send it to the ML. (Done Oct 13) * Schedule toward the submission of the draft Proposed schedule is approved. Oct 13 Review of the Chapter 7 then Chapter 1 and 2. Oct 20 Review of the rest, Open issues, style check Oct 27 Submission to the GGF editor [Projection] Mid Nov. Comments from GGF editor received. End Nov. Comments are addressed and returned. Early Dec. 60 day public review starts. Early Feb. review comments are collected. Mid Feb. updated draft is returned to GGF editor. End Feb. approval by GGF. Carry on items to version 2.0 will be described in chapter 11 "Open Issues". Action: Keisuke, to compile issues raised at GGF15 sessions. (Done Oct 12) * Review of the proposed draft for the chapter 7 AAF in the draft 0.51. - Relationship to SDD. For the version 1.0, we don't have any dependencies to SDD. Convergence with SDD will be addressed in the open issues chapter. - Version format. Mike's question: Why do we use xsd:string type to describe version instead of using separate types such as major, minor, etc. Answer: The spec should accept various version numbering semantics enforced by any development environment (tools) to be used with ACS. - Uniqueness of AAID Sachiko's question: If different producers try to create AA instances that have same AAID, is it failed? Answer: Yes. AAID must be unique in a repository. The combination of the name and version element in the AAID should be kept unique in the repository between producers. - AccessConstraint. This element specifies security policy for information contained in Application Archive, thus mainly it should be about access control. The generic security policy should be described and kept by system implementation rather than by each AA. This element should be optional. - CheckSum for each content. The term "digest value" may be more appropriate. We need check other standards like XML Signature. - Differential AAD. Mike's question: Can binary differentials be included in AA? Answer: The differential here is in a granularity of Application Content. Differential updates finer than it, for example using a binary patch, is not specified in ACS, though they can be practiced in a implementation specific way with prior agreement between producers and consumers. - Version management. We currently have only simple attributes that indicate parent and immediate children. For future discussion, Mike suggested adding attributes to describe richer dependency information between AAs. - Physical format. Mike suggested having auto installable format in order to help automated provisioning. One may execute GetContents automatically to obtain content on which it depends. Agreed to discuss about this as an open issues. Action: Keisuke, to merge section 1.3 Notational Conventions and 1.4 Namespace (posted on Sep 26 by Sachiko) to the draft. (Done Oct 14) Action: Sachiko, to add XML schema diagrams. Action: Keisuke, to compress and simplify the description, especially the Differential AAD section. Action: Mike, to post his proposal for AAD to the ml. (Done Oct 12) * Updates Keisuke attended CDDLM teleconf on Oct 12 and discussed possible interaction between ACS and CDDLM. The conclusion is either of three sequences Stuart proposed will work and there is no preference from ACS view. * Next meeting Date: Oct 19 Wed 20:00 EDT/Oct 20 Thu 9:00 JST Calling #: will be announced later

1 0

Archive Descriptors or Resource Propoperties or Both
by Michael Behrens 17 Oct '05

17 Oct '05

For the draft spec 0.51, I propose these additional optional elements. Perhaps they could be both in the AAD and exposed as resource properties: <aaf:Requires>xsd:string</aaf:Requires>* The AAID which this one content requires. This can be used to automatically obtain all dependencies. <aaf:Conflicts>xsd:string</aaf:Conflicts>* The AAID which this one conflicts with. <aaf:Replaces>xsd:string</aaf:Replaces> The AAID which this one replaces. <aaf:ReleaseNotes>xsd:string</aaf:ReleaseNotes> (like a readme.txt content)* <aaf:ContentType >xsd:string</aaf:ContentType > The type of content or the purpose of the content: Patch, Base, Differential, Data. Data means non-executable static data. <aaf:GroupName>xsd:string</aaf:GroupName> This is the group of the AA. This way, a hierarchy can be rendered/determined as needed. <aaf:PatchVersion>asd:string</aaf:PatchVersion>? Indicates the patch number or release if this content is a patch Add to AAID? <aaf:icon> <small> </small>? <large> </large> </aaf:icon>? This would be a binary PNG 32x32 or 64x64 for use with IDEs, etc. ALSO: Installation Package - Mention that an application content (AC) might be stored as an auto-installable format, such as an .msi, or installable/executable jar, or possibly even an .sdd? This would make provisioning/installation (silent installs) easier perhaps. Just an idea for future discussion. I presume we could use SDD equivilants for these and the other ADD elements - if so, perhaps that needs to go into the SDD section that Tom is working. Multiple Pulls with dependency could be managed using the dependency tree - perhaps using SDD elements? -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)

2 1

[Fwd: BOUNCE acs-wg@ggf.org: Non-member submission from [Allen Luniewski <luniew@almaden.ibm.com>]]
by Keisuke Fukui 16 Oct '05

16 Oct '05

Forwarding a bounced e-mail.

1 0

RE: [acs-wg] RE: Your comments on the draft spec.
by Ziu, Peter 15 Oct '05

15 Oct '05

Keisuke, I read your .ppt sent to OGSA/CDDLM, I don't think there is a problem since I don't seen anything restricting a job document to be in an AA. The concern I had that caused me to comment was a 'best practices' concern that perhaps is best address in OGSA and does not need to be addressed in the ACS spec. It may need to involve other building off our spec, and adding constraints on what should be in certain AAs. My simple concern was that the job doc that starts the ball rolling should be encapsulated in something with a version number, and protected against undesired modification via signature, much like an AA can do. As you pointed out, we are not preventing this, so the comment can be addressed elsewhere. I agree, I think that for the most part we don't put restrictions on what content can go in the AA, and that is reflected in 3.1.1. I also agree, it is reflected in 3.1.4 that job "instance" should NOT be maintained. I think this is well stated. We should perhaps clarify that this does not mean that JSDL is excluded from an AA. To me job "instance" means any dynamic state concerned with an executing job, and this does not restrict the ability for a job managing entity to obtain JSDL from an AA, correct? Food for thought: Since AA's can have external references, there is nothing stopping a "root" AA from containing nothing but a JSDL doc, and a reference to the main content AA. If this type of job submittal format was optionally allowed by OGSA, then an EPR of a "root" AA could be submitted to the job managing entity to kick off a job, not just a JSDL doc. This would mean that the actual execution instruction is conveniently archived in the repository with a version and signature. Pete. -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Keisuke Fukui Sent: Friday, October 14, 2005 1:44 AM To: Ziu, Peter Cc: acs-wg(a)ggf.org Subject: Re: [acs-wg] RE: Your comments on the draft spec. 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

2 1

RE: [acs-wg] [ogsa-d-wg] OGSA-D-WG description for ACS specification:
by Ziu, Peter 14 Oct '05

14 Oct '05

Looks very good Mike, we should include it after dialog from ogsa-d. Perhaps we could be more specific about replication after this dialog? Pete. -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Michael Behrens Sent: Thursday, October 13, 2005 10:20 PM To: acs-wg(a)ggf.org; ogsa-d-wg(a)ggf.org Subject: [acs-wg] [ogsa-d-wg] OGSA-D-WG description for ACS specification: This is being posted to the ACS and OGSA-D group for inter-group communication purposes. ACS needs to be aware of data services as they will impact the ACS specification at some point in time. The ACS specification has a non-normative section for describing relationships with other groups/activities. This is the proposed paragraph for your review - what do you think? "The OGSA Data Working Group defines the data services which provide for distribution of data on the grid. ACS can utilize protocols being specified such as Byte-IO, GridFTP, and possibly Replication. ACS provides an extension point for protocols which allow implementations to specify which protocols are supported. The ACS team has reviewed their briefings and draft documents with interest. Interaction with the OGSA Data Working group is expected to increase during the development of the next version of this specification." -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)

1 0

New draft 0.53
by Keisuke Fukui 14 Oct '05

14 Oct '05

Folks, fyi, I have updated the draft and uploaded on the DocMan. You can retrieve that from the below link: https://forge.gridforum.org/projects/acs-wg/document/draft-ggf-acs-spec-0.5… It include the below change: - Updated with review comments at the TeleConference. - Inclusion of the section 1.3, 1.4 and 3.3.2. - Redone format and styles for entire document. P.S. Please note that I have to update the sections in Chapter 7 to resolve the remained issues by next meeting. -Keisuke

1 0

RE: Your comments on the draft spec.
by Ziu, Peter 14 Oct '05

14 Oct '05

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(a)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

2 1

Sections in the draft.
by Keisuke Fukui 13 Oct '05

13 Oct '05

Hello, Tom, I hope we are close to have our first draft for the ACS specification 1.0 to be submitted. Although I guess you are so busy this time, we have below sections waiting for your inputs. 3.3.1 OASIS SDD TC - Tom 3.3.5 OASIS WSDM TC - Tom 6. Manageability - Tom Please let us know if you can post your drafts in this week. You have invaluable expertise for these areas and we depends on you. If you cannot, someone in our team will draft them then ask you to review it. However, it may make you and others bothered in reviewing. Especially, if it was me to draft them, we may end up with miserable descriptions as a start and bother someone much more. So I believe it is the best in net effect if you can draft them. I appreciate your contributions so far and this time again. Regards, Keisuke Fukui

1 0