Etienne, all, I put your points on the agenda for Thursday. Nevertheless, the main items to work on stay the same. Thanks, Morris
-- -----Ursprüngliche Nachricht----- -- Von: Etienne URBAH [mailto:urbah@lal.in2p3.fr] -- Gesendet: Freitag, 5. November 2010 20:19 -- An: Riedel, Morris; Johannes WATZL -- Cc: pgi-wg@ogf.org; lodygens@lal.in2p3.fr; edgi-na2@mail.edgi-project.eu -- Betreff: OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for requirements -- Wichtigkeit: Hoch -- -- Morris and Johannes, -- -- Thank you for the notes of the PGI sessions held at OGF30 in Brussels on -- 26 October 2010. -- -- Reviewing them and the associated requirement spreadsheet at -- http://forge.gridforum.org/sf/go/doc16080?nav=1 I have found several -- issues : -- -- -- A) Green color of spreadsheet cells for vote count (column T) -- ------------------------------------------------------------- -- At the end of the notes for session 3, it is mentioned that I 'globally -- approve all of the greens'. -- I confirm that I expressed this position. -- But inside the spreadsheet, the vote count cells (column T) which were -- green have turned yellow ! -- Then, my above position has no meaning anymore. -- -- -- B) Requirement supported by EDGI -- -------------------------------- -- Inside the requirement spreadsheet, you took into account only the 26 -- 'Mandatory requirements' from my mail below. -- -- In fact, you should have taken into account the 'Complete list of -- requirements' specified at the end of the same mail. -- -- Therefore, I have updated the requirement spreadsheet with this complete -- list (70 requirements). -- -- -- C) Votes for requirements WITHOUT 'yes' status -- ---------------------------------------------- -- Inside the process of voting for requirements, we were supposed to vote -- ONLY for requirements having 'yes' status. -- -- Inside the requirement spreadsheet, it seemed to me that some votes were -- for requirements WITHOUT 'yes' status. -- -- In order to be sure, I have reactivated the display of the column -- displaying 'Agreement OGF29' (column F), and I have colored in yellow -- all cells NOT containing 'yes'. -- -- This clearly shows that MANY votes were for requirements WITHOUT 'yes' -- status. -- -- In particular, requirement 10 'SSL certificates of servers MUST be -- signed by a CA belonging to IGTF ' gathered 3 votes. -- -- This indicates that some requirements NOT having 'yes' status still have -- a great importance for several PGI members. -- -- Therefore, I propose to perform a new round of voting, allowing votes -- for all requirements WITHOUT consideration of their previous status. -- -- If this proposal is accepted, I would also vote for following requirements : -- 10, 12, 13, 14, 15, 18, 27, 38, 39, 41, 49, 51, 53, 75, 127, 161, 162, -- 164, 167 -- -- -- Conclusion -- ---------- -- Counting of votes has perhaps been performed too hastily. -- -- The attached 'PGI-Requirements-2010-10-26-Review-Etienne.xls' file -- contains the 'Complete list of requirements' of EDGI, and displays the -- 'Agreement OGF29' column (but I have NOT added any EDGI vote for any -- requirement NOT having 'yes' status). -- -- I suggest that each PGI member carefully checks the content of this -- spreadsheet. -- -- -- Anyway, I still agree with the priorities stated at OGF30 : -- 1) XML rendering for GLUE 2.0 -- 2) Usage of GLUE 2.0 entities and attributes inside JSDL -- 3) Usage of GLUE 2.0 entities and attributes inside JSDL for SPMD and MPI -- 4) Usage of GLUE 2.0 entities and attributes inside JSDL to describe -- Applications -- 5) Usage of GLUE 2.0 entities and attributes inside BES -- -- -- Best regards. -- -- ----------------------------------------------------- -- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS -- Bat 200 91898 ORSAY France -- Tel: +33 1 64 46 84 87 Skype: etienne.urbah -- Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -- ----------------------------------------------------- -- -- -- -------- Original Message -------- -- Subject: Re: OGF PGI - Requirements triggered by the EDGI Use Cases -- Date: Tue, 19 Oct 2010 14:33:25 +0200 -- From: Etienne URBAH <urbah@lal.in2p3.fr> -- To: Morris RIEDEL <m.riedel@fz-juelich.de>, Johannes WATZL -- <watzl@nm.ifi.lmu.de>, pgi-wg@ogf.org -- CC: lodygens@lal.in2p3.fr, edgi-na2@mail.edgi-project.eu -- -- Morris, Johannes and all, -- -- Please find below the OGF PGI requirements triggered by the EDGI Use Cases : -- -- -- +-----------------------------+ -- | A) Mandatory requirements | -- +-----------------------------+ -- Following is the list of requirements with 'yes' status which are seen -- as mandatory for EDGI. Interoperation would be very difficult without them. -- -- -- Information functionality -- ------------------------- -- 1 : All grid entities (if possible) MUST be described using the GLUE -- model. If not possible, extensions for the GLUE model are necessary. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS1 -- -- 5 : The Execution Service MUST NOT expose detailed information about -- the GLUE entities which the Execution Service does not manage (all that -- are not expressed by the computing part of GLUE). For example, Storage -- Element GLUE entity NOT exposed by Execution Service, NO details about -- Storage entity. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS4 -- -- 165 : For already finished Activities, the Information functionality -- SHOULD accept requests querying the Activity Status, but MAY return an error -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS9 -- -- 172 : In order to prevent overloading the Execution Service (which has -- performance requirements for Activity Management), the Information -- functionality SHOULD be separated from the Execution Service -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS14 -- -- -- Security (Authentication, Authorization, Delegation) -- ---------------------------------------------------- -- 9 : If server authentication to clients, then it must be done with -- X.509 certificates on TLS (as mandatory option, allowing also other -- mechanisms additionally) -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA1 -- -- 11 : Each Service MUST publish the Authentication and Authorization -- methods accepted by its Endpoints in conformance with GLUE recommendations -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA2 -- -- 32 : There must be a mechanism which allows users to manage Activities -- submitted by other users (access control lists/methods/policies). In -- order to authorize (or not) an request on an Activity, each instance of -- the Execution Service MUST enforce a consistent authorization method. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA9 -- -- -- Application Repository -- ---------------------- -- 34 : An easy way of launching applications or pre-configured -- /pre-installed software w/o specifying location details. -- Installed/pre-configured ones should be exposed as well as part of the -- resource description. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAR1 -- -- -- Accounting -- ---------- -- 36 : The Execution Service SHOULD provide Accounting records for each -- managed Activity. e.g. OGF Usage Records, for tracking resource usage. -- Most likely improving UR in terms of network and storage resource -- tracking and improvements of compute parts of multi-core-business. -- Grid-level attributes (for example: start-time on Grid vs. in batch-system). -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAc2 -- -- 173 : In order to prevent overloading the Execution Service (which has -- performance requirements for Activity Management), the Accounting -- functionality MUST be separated from the Execution Service -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAc1 -- -- -- Logging and Bookkeeping -- ----------------------- -- 37 : WITH ITS ORIGINAL TITLE : In order to permit efficient Log -- analysis and Security audit, some Logging and Bookkeeping functionality -- MUST secure persistence at the grid level of Activity logs from various -- logging systems and MUST permit Client access to these Activity logs, -- even after Activities have finished. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqLB1 -- -- -- -- Activity Management -- ------------------- -- 45 : On creation of an Activity, the Execution Service MUST return to -- the Client an Activity ID permitting the Client to perform subsequent -- actions (Query, Cancel, ...) on this precise Activity -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM4 -- -- 62 : The Execution Service MUST log enough grid information inside -- logging systems (which MAY vary during the lifetime of the Activity), in -- order to permit efficient Log analysis and Security audit -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6 -- -- 67 : If a Client queries for an already finished Activity, the -- Execution Service MAY response with an error -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6.8 -- -- 74 : The execution service MUST NOT expose activity information when -- queried for resource information -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6.1... -- -- 94 : Requirement to have a purge (maybe called wipe) operation. -- Removing all presence (except logs & usage records) of the activity -- (when it is not longer active or once finished). This functionality is -- only allowed on any final state according to the PGI state model. The -- functionality is not supposed to kill Activities, that is why its only -- allowed on final states. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM20 -- -- -- Job Description -- --------------- -- 100 : The Job Description document MUST reference all grid entities in -- conformance to the GLUE specification -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD3 -- -- 101 : The Job Description document specification MUST permit the Client -- to request automatic data stage-in and stage-out -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD4 -- -- 107 : Job Description should be only used for Job Description not for -- any kind of feedback. Job status information should not be communicated -- with a 'changed JSDL' -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD11 -- -- -- State Model -- ----------- -- 119 : The Execution service MUST support a common state model -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqSM1 -- -- 131 : The Execution service MUST perform the transition between -- Activity states requested by the Client ONLY if it makes sense. -- Otherwise, the Execution service MUST return an error to the Client. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqSM10.... -- -- -- Data Management -- --------------- -- NO requirement with 'yes' status is essential. -- -- -- Non functional -- -------------- -- 146 : Software components (Services and Clients) MUST ease traceability -- of the original author of a request -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF3 -- -- 147 : Software components (Services and Clients) MUST generate adequate -- logs -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF4 -- -- 148 : Software components (Services and Clients) MUST generate and -- propagate meaningful error messages, including context description -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF5 -- -- 149 : Specifications SHOULD prevent the occurrence of SPOFs and bottlenecks -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF7 -- -- 154 : Basic SW Engineering basic principles - implementation -- encapsulation, separation of policies, construction by composition, -- don't re-invent new mechanisms when some existing -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF12 -- -- 160 : Execution Service MUST NOT try to provide ALL grid -- functionalities, but MUST have a well defined scope, and MUST work -- together with other grid services : Security, Accounting, Data (Storage, -- Movement, Catalog, ...), perhaps Information, Logging and Bookkeeping -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF13 -- -- -- +------------------------------------+ -- | B) Complete list of requirements | -- +------------------------------------+ -- Following is the complete list of requirements with 'yes' status which -- are seen as useful for EDGI. -- -- Information functionality : 1, 3, 4, 5, 6, 8, 165, 166, 172 -- -- Security (Authentication, Authorization, Delegation) : 9, 11, 17, 19, -- 20, 21, 22, 32 -- -- Application Repository : 34 -- -- Accounting : 36, 173 -- -- Logging and Bookkeeping : 37 WITH ITS ORIGINAL TITLE -- -- Activity Management : 43, 44, 45, 46, 55, 58, 59, 62, 63, 64, 65, 66, -- 67, 68, 74, 81, 82, 86, 90, 94 -- -- Job Description : 100, 101, 104, 107, 112, 114, 116, 118 -- -- State Model : 119, 120, 121, 122, 123, 124, 125, 128, 131, 134 -- -- Data Management : 143 -- -- Non functional : 145, 146, 147, 148, 149, 150, 154, 156, 159, 160 -- -- -- Best regards. -- -- ----------------------------------------------------- -- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS -- Bat 200 91898 ORSAY France -- Tel: +33 1 64 46 84 87 Skype: etienne.urbah -- Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -- -----------------------------------------------------