[dcifp-bof] Group charter proposal

[Craig.A.Lee at aero.org]

Alexander,

I strongly support this group.  To demonstrate that I strongly 
support this group, I have a bunch of suggestions! ;->

1) The word "profile" only occurs once (in one of the Seven 
Questions).  If I understand correctly, the goal of DCIfed is to 
produce a profile of existing standards that supports DCI federation. 
I assume that the DCI Fed Spec will be this profile.

2) While we certainly want to evaluate existing OGF standards for 
this purpose, I think we'd also want to consider standards from other 
SDOs, e.g., OVF from DMTF, etc.

3) The topic of the Informational Doc is not explicitly stated.  I 
assume this will present the group's analysis and justifications for 
what to put in the Spec and what to leave out.  This analysis should 
also include a "gap analysis" in case there are no appropriate 
candidate standards for necessary functionality XYZ.   Another 
possibility is that two specs exist for different functions, but they 
are incompatible in some way.

4)  I think the two initial Usage Scenarios are fine.  I would leave 
the door open, however, for additional scenarios.  See (5).  We can't 
do every usage scenario, but there might be other important ones.

5)  Security is only mentioned tangentially.  Federating DCIs will 
mean federating their security models.  Will DCI Fed simply say that 
everybody must use the same security infrastructure, or will it 
specify how different security mechanisms can nonetheless 
interoperate?  As I have said elsewhere, ID mgmt and role-based 
authorization in VOs to support business-to-business and 
"inter-cloud" apps will be a central issue.

6)  Besides usage scenarios, we might also want to consider 
federation scenarios.  Pair-wise federation might be the easiest to 
manage.  A "hub and spoke" model with a centralized federation hub 
might be the next step up.  A complete p2p federation model might be 
the most general and most complete approach (and most difficult). 
I'm not saying that we have to consider these things, but in the 
past, OGF has been accused of trying to "boil the ocean" by defining 
"complete architectures" that have to be adopted in totality in order 
to do anything.  This makes adoption very difficult.  If there are 
some simple federation scenarios that require fewer and simpler 
standards to achieve, that nonetheless addresses a significant 
segment of users that need federation, then we might want to identify 
that as a specific profile.

7)  "Liaisons" are not mentioned anywhere.  In order to maximize the 
quality and impact of this group's work, there should be specific 
liaisons with other groups, e.g., CSA, DMTF, GICTF, etc.  This work 
will also be of interest to Cloud-Standards.org.  Besides helping to 
refine the usage scenarios and federation scenarios, this will also 
help get earlier and wider visibility for this group's work.  Perhaps 
we could even get some additional people to help with the real work. 
The OGF Board and GFSG should help in this liaison function.

Andre and Alan may have further comments on these suggestions. 
Hopefully we can all converge quickly to get this group approved.

--Craig

At 2:57 PM +0200 8/10/10, Alexander Papaspyrou wrote:
>Folks,
>
>after a rather long period of silence, covering holidays, the epic 
>search for a co-chair and secretary, and document polishing, I am 
>happy to send around the final draft for the group charter.
>
>Major changes include the fixation to the "Management" area (thanks 
>Andre), the name change (as discussed in Chicago), the contribution 
>to the reference model (thanks Craig), and volunteers for chair and 
>secretary positions (BIG thanks, Gary and Andrew).
>
>Here you go:
>--8<-- snip --8<--
>Charter for DCIfed-WG
>
>Group Abbreviation
>DCIfed-WG
>
>Area
>Management
>
>Group Leadership
>     Alexander Papaspyrou    alexander.papaspyrou at tu-dortmund.de     Chair
>     Gary Mazzaferro.        garymazzaferro at gmail.com                Chair
>     Andrew Edmonds          andrewx.edmonds at intel.com               Secretary
>
>Group Summary:
>The purpose of this group is the development and spread-out of a practical set
>of protocols and formats to interface between different types of Distributed
>Computing Infrastructures in a secure, SLA-managed manner. We will 
>focus on the
>federation of such DCIs for two usage scenarios: (1) delegation of 
>workload from
>one domain into the other, covering job description, submission, and 
>monitoring;
>and (2) leasing of resources, including resource definition, provisioning, and
>monitoring. The work of this group will base on existing protocols 
>and standards
>in order to ensure fast delivery and highest possible 
>synchronization with other
>groups.
>
>
>Charter Focus / Purpose and Scope:
>Infrastructure federation is becoming an increasingly important 
>issue for modern
>Distributed Computing Infrastructures (DCIs): Dynamic elasticity of 
>quasi-static
>Grid environments, incorporation of special-purpose resources into 
>commoditized
>Cloud infrastructures, cross-community collaboration for 
>increasingly diverging
>areas of modern e-Science, and Cloud Bursting pose major challenges on the
>technical level for many resource and middleware providers. Especially with
>respect to increasing cost of operating data centers, the intelligent, yet
>automated and secure sharing of resources is a key factor for success.
>
>The DCI Federation Working Group (DCIfed-WG) will, after initial research,
>deliver a specification for the automatically negotiated, SLA-secured,
>dynamically provisioned federation of resources and for Grid- and Cloud-type
>infrastructures. The scope of the specification will include (1) the 
>delegation
>of workload from one domain into the other, covering job description,
>submission, and monitoring; and (2) leasing of resources, including resource
>definition, provisioning, and monitoring.
>
>This group will focus on the creation of a specification for compute-centric
>federation. This is both necessary and sufficient to allow for interoperable
>implementations.
>
>DCIfed aims to address the needs of different stakeholders:
>  * Providers to incorporate dynamic elasticity into their DCI based on current
>    demand;
>  * Aggregators to provide a simplified view on infrastructure federations;
>  * Integrators to offer advanced management services beyond the boundaries of
>    current infrastructure types;
>  * Vendors to use DCI-abstracted data centers in an application-driven,
>    on-demand fashion;
>  * Users to benefit from otherwise separate infrastructures in a coherent,
>    unified, and transparent way.
>
>The scope will be limited to the high-level federation of DCIs with respect
>to delegation of workload and leasing of resources. This includes means for
>describing, negotiating, and agreeing upon the service provided and 
>consumed by
>the federated systems; the description, submission, and monitoring 
>of workload;
>the definition, provisioning, and monitoring of resources. Data management
>details beyond providing endpoints for transfer are excluded; the 
>same holds for
>network management details beyond the absolute necessities for leasing a
>resource (i.e. providing a publicly accessible IP).
>
>There are a number of existing standards within OGF which shall serve as basis
>for the full protocol, interface, and data representation documents 
>for DCIfed:
>
>  * WS-Agreement
>  * JSDL
>  * GLUE
>  * OGSA-BES
>  * OCCI
>  * UR
>
>
>Exit Strategy:
>The work of this group will be deemed complete with the finalization of the
>documents.
>
>
>Goals/Deliverables:
>   Title: DCI Federation Use Cases
>   Abstract:
>     Use cases for DCI federation, including stakeholders, entities, the
>     delegation/leasing lifecycle, and associated management tasks.
>
>   Type: Informal Document
>     Milestones:
>       Draft           -- 2010-11 (post-OGF30)
>       Public Comment  -- 2011-03 (pre-OGF31)
>       Publication
>
>   Title: DCI Federation Specification
>   Abstract:
>     Technical specification of protocols, interfaces, and data representation
>     for the DCI Federation specification with one transport rendering.
>
>   Type: Recommendation Document
>     Milestones:
>       First Draft     -- 2011-02
>       Second Draft    -- 2011-05 (post-OGF31)
>       Public Comment  -- 2011-07 (pre-OGF32)
>       Publication
>
>
>Seven Questions:
>
>1. Is the scope of the proposed group sufficiently focused?
>Yes. The group will define a specification on top of existing interfaces and
>over-the-wire formats for the federation of DCI environments. The main focus
>will be to address two compute-centric use cases, namely the delegation of
>workload and the leasing of resources. As far as possible, the group 
>will reuse
>existing standards, integrate them towards a higher-level product, and
>contribute back experiences, implementations, necessary 
>modifications to the SDO
>bodies embracing the specifications in question.
>
>2. Are the topics that the group plans to address clear and relevant for the
>    Grid research, development, industrial, implementation and/or application
>    user community?
>Yes. Current Grid deployments are usually limited to their own 
>domain which---in
>many Service Grid cases---limits the usability of resources within the own
>community. Also, Cloud environments are usually constrained to a single
>provider, not allowing for mix-and-match applications. Sophisticated use cases
>such as elasticity, Grid-Cloud integration, cross-community collaboration, and
>"Cloud Bursting" are highly relevant, yet not supported.
>
>3. Will the formation of the group foster (consensus-based) work 
>that would not
>    be done otherwise?
>Yes. Current efforts are focusing on atomic aspects, providing no integrated
>profile for the aforementioned use cases. For example, GRAAP addresses the
>description, establishment, and monitoring of SLAs, but provides no
>domain-specific support for DCI federation; OGSA-BES/HPC-BP primarily focuses
>on job submission, but supports no delegation; OCCI Infrastructure provides
>means for IaaS description and provisioning, but not for cross-domain leasing.
>As such, this initiative is unique within OGF and provides an opportunity to
>deliver a strategic technology platform for the integration of the 
>complementary
>Grid and Cloud Computing areas.
>
>4. Do the group's activities overlap inappropriately with those of another OGF
>    group or to a group active in another organization such as IETF or W3C?
>No. Although the work within the group will heavily base on existing 
>standards,
>especially from within OGF, the integration effort is unique and not 
>interfering
>with other groups' interest. On the contrary, the results from this group will
>provide valuable feedback and additional input to the existing WGs in order to
>drive forward the applicability and quality of their work in a 
>relevant complex
>field application. Interactions towards lower management levels will 
>be closely
>aligned with the efforts in PGI-WG.
>
>5. Are there sufficient interest and expertise in the group's topic, with at
>    least several people willing to expend the effort that is likely to produce
>    significant results over time?
>Yes. The group has already gathered a sufficient number of active contributors
>to deliver the specification within the aspired timeline. 
>Participants comprise
>both the academic and the industrial domain. Also, both the consumer and the
>provider site are represented. A significant amount of existing work can be
>derived from an established project and serve as basis from which consensus
>can be reached. In the BoF session at OGF28, ten out of 24 participants stated
>interest in helping out.
>
>6. Does a base of interested consumers (e.g., application developers, Grid
>    system implementers, industry partners, end-users) appear to exist for the
>    planned work?
>Yes. Several NGIs have stated interest in connecting their national Grids
>through means of DCIfed. Also, ongoing discussion with Cloud 
>providers indicates
>that federation mechanisms are of high interest. Two research projects have
>shown interest in using DCIfed for adding elasticity to their existing Grid
>ecosystem. In addition, the five major resource management systems 
>within German
>D-Grid have expressed their support for DCIfed and will actively contribute to
>the group discussion and implement the outcome specification.
>
>7. Does the OGF have a reasonable role to play in the determination of the
>    technology?
>Yes. OGF determines standards in the Grid Computing domain. In 
>addition, ongoing
>embracement of Cloud Computing efforts is shown through groups such as OCCI.
>Especially with respect to increasing cost of operating data centers, there
>is a strong interest in intelligent, yet automated and secure sharing of
>resources beyond the boundaries of either paradigm. Moreover, most actors from
>the domain of Grid space are also active in Cloud Computing. The high-level
>interoperation approach of DCIfed will, in addition, significantly add to the
>ongoing efforts on creating a reference model for Distributed Computing
>Infrastructures.
>-->8-- snap -->8--
>
>Please go through it and flame at your discretion, but do so until
>
>   Friday, August 13, 2010, 12:00pm (noon)
>
>Whatever comes in, I will massage into the document and send it to 
>GFSG on Monday morning.
>
>Looking forward to being a real WG!
>
>Best,
>Alexander
>
>--
>Alexander Papaspyrou
>alexander.papaspyrou at tu-dortmund.de
>
>
>Attachment converted: Macintosh HD:Alexander Papaspyrou 1.vcf 
>(TEXT/ttxt) (020E48A5)
>Attachment converted: Macintosh HD:smime 202.p7s (    /    ) (020E48A6)