[Pgi-wg] OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for requirements
Morris Riedel
m.riedel at fz-juelich.de
Sun Nov 7 09:46:15 CST 2010
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 at lal.in2p3.fr]
>-- Gesendet: Freitag, 5. November 2010 20:19
>-- An: Riedel, Morris; Johannes WATZL
>-- Cc: pgi-wg at ogf.org; lodygens at lal.in2p3.fr; edgi-na2 at 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 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
>-- -----------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101107/5cacab2f/attachment.bin
More information about the Pgi-wg
mailing list