[Pgi-wg] OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for requirements

Sun Nov 7 18:10:41 CST 2010

Oxana,
I'm not sure "blessed" is the right way of putting it :-). I think that Morris and Johannes were trying to prioritize the proposed requirements based on the most objective metric available to them immediately after the discussion - the number of use cases that included the requirement. If we do not prioritize them at all, then we: a) have quite a few requirements to meet, b) have no basis on which to make trade-offs, and c) don't have a good starting point - as in meet these X requirements - then see what else we can fit in.

A

-----Original Message-----
From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of Oxana Smirnova
Sent: Friday, November 05, 2010 3:53 PM
To: pgi-wg at ogf.org
Subject: Re: [Pgi-wg] OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for requirements

Hi all,

I concur with Etienne, and would like to thank him for doing this careful analysis!

If we are going to use the "vote count" as a serious justification for further decisions, it has to be made in a consistent manner.

If however this count does not matter, since the high-level picture is already "blessed", then of course re-counting is a futile exercise.

Cheers,
Oxana

P.S. the heroic effort of PGI requirements counting during the coffee break is actually illustrated in the attachment ;-)

On 05.11.2010 20:19, Etienne URBAH wrote:
> 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 at 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 at lal.in2p3.fr>
> To: Morris RIEDEL <m.riedel at fz-juelich.de>, Johannes WATZL 
> <watzl at nm.ifi.lmu.de>, pgi-wg at ogf.org
> CC: lodygens at lal.in2p3.fr, edgi-na2 at 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/Re
> qIS1
>
> 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/Re
> qIS4
>
> 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/Re
> qIS9
>
> 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/Re
> qIS14
>
>
> 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/Re
> qAA1
>
> 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/Re
> qAA2
>
> 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/Re
> qAA9
>
>
> 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/Re
> qAR1
>
>
> 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/Re
> qAc2
>
> 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/Re
> qAc1
>
>
> 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/Re
> qLB1
>
>
>
> 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/Re
> qJM4
>
> 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/Re
> qJM6
>
> 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/Re
> qJM6.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/Re
> qJM6.16
>
>
> 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/Re
> qJM20
>
>
> 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/Re
> qJD3
>
> 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/Re
> qJD4
>
> 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/Re
> qJD11
>
>
> State Model
> -----------
> 119 : The Execution service MUST support a common state model
> http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Re
> qSM1
>
> 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/Re
> qSM10.1
>
>
>
> 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/Re
> qNF3
>
> 147 : Software components (Services and Clients) MUST generate 
> adequate logs
> http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Re
> qNF4
>
> 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/Re
> qNF5
>
> 149 : Specifications SHOULD prevent the occurrence of SPOFs and 
> bottlenecks
> http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/Re
> qNF7
>
> 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/Re
> qNF12
>
> 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/Re
> qNF13
>
>
> +------------------------------------+
> | 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 at lal.in2p3.fr
> -----------------------------------------------------
>
>
>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg