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

Fri Nov 5 14:53:01 CDT 2010

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/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.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/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.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/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 at lal.in2p3.fr
> -----------------------------------------------------
>
>
>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGI-counting.jpg
Type: image/jpeg
Size: 34251 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101105/28ef18c5/attachment-0001.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oxana_smirnova.vcf
Type: text/x-vcard
Size: 293 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101105/28ef18c5/attachment-0001.vcf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101105/28ef18c5/attachment-0001.bin 