perfsonar development work

["Eric L. Boyd" <>]

Greetings,

Apologies for the delay in getting this out to the group. Please find 
included definitions we agreed upon in France, action items to flush out 
some areas of new agreement, and notes from discussions we began in 
various areas.

--Eric

--
Eric Boyd
Director of Performance Architectures and Technologies
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI  48104  USA
(734)352-7032

The Fall 2006 Internet2 Member Meeting:
Because the best way to predict the future is to keep inventing it.
http://events.internet2.edu/2006/fall-mm/ 

PerfSONAR Service
=================
We agreed to the following definition of a perfSONAR Proposed service:

ACTION ITEM: Put this service definition on the website (Lead: Susan Evett)

1) Adheres to the Protocol Standard
        a) Syntax (Binary representation of message, defined by OFG NMWG 
schema)
        b) Semantics (Business Logic)

        ACTION ITEM: Detail process for creating a protocol standard and an 
example (Lead: Martin
        Swany, Asst: Joe Metzger, Nicolas Simar).

        TIMELINE: Process and first example by 12/06

        ACTION ITEM: Enumerate business logic for existing service types (All 
developers)

        Notes: We want to create versioned RFCs for protocol standards.

        Initial thoughts on process:

        a) Define Problem

                Document why this protocol is needed

        b) Define semantics

                Appropriate interaction
                Control flow
                Document it.

        c) Define how to represent it

                Extension to schema needed?
                Either way (extended or not extended), Document it

        d) Review with goal of initial acceptance or denial

        e) Implementation

        f) Final review

2) Obeys naming scheme for services

        ACTION ITEM: Propose/shepherd naming scheme for services (Lead: 
Maciej Glowiak, Asst: Martin Swany)

        Notes: Consider service type, event type, message type, data type, 
language of
        implementation, authoring organization, service version #

        ACTION ITEM: Extend individual service naming scheme to cover bundles 
(Lead: Eric Boyd [placeholder])

3) Has an open source, non-coercive license

        ACTION ITEM: List sample set of appropriate licenses on website 
(Lead: Eric Boyd,
        Asst: Nicolas Simar)

        Notes: Reference Apache Licenses, Internet2 Intellectual Property 
Framework

4) Meets the perfSONAR Documentation Standard

        ACTION ITEM: Write the Documentation Template (Lead: Martin Swany)

        TIMELINE: Template by 12/1/06

        Action ITEM: Get developers of existing services to write it (Lead: 
Nicolas Simar)

        ACTION ITEM: Editorial control (Susan Evett)

        TIMELINE: Complete before next individual service release or next 
group release

        Notes: Ideas to include:

                -- What the service offers
                -- Protocol description reference
                -- Authors
                -- Document extent of commitment to support (timeframe or 
best effort)
                -- License (or license reference)
                -- Links to existing installations
                -- How to isntall
                -- Dependences (e.g. Tomcat, Axis)
                -- Languages (e.g. Java)

A perfSONAR Service meets the following additional criteria:

5) Participates in a successful bake-off

        REQUIREMENT: Two or more implementations of the protocol standard

        ACTION ITEM: Define bake-off procedure. (Lead: Joe Metzger, Asst: 
Andreas,
        Leobino, Michalis)

        TIMELINE: 01/15/06

In order to be listed on the perfSONAR website and be authorized to use the 
perfSONAR name,
a perfSONAR service must meet the above criteria, as judged by the perfSONAR 
steering
committee (or their delegates).

PerfSONAR Client
================
We agreed to the following definition of a perfSONAR Client:

1) Adheres to the Protocol Standard (see above) to communicate with 1+ 
perfSONAR
        Services or perfSONAR Proposed Services

2) Meets the PerfSONAR Documentation Standard (see above)

In order to be listed on the perfSONAR website and be authorized to use the 
perfSONAR name,
a perfSONAR client must meet the above criteria, as judged by the perfSONAR 
steering
committee (or their delegates).

PerfSONAR Bundle
================
We agreed that a perfSONAR Bundle is:
        -- defined by one or more groups (e.g. ESnet, G2 JRA1, Internet2, LHC)
        -- a set of perfSONAR Services (as defined above)
        -- with documentation
        -- with release management / testing / package management
        -- with a source code repository

Mandatory requirements:
        -- All services in a bundle must qualify as perfSONAR services or 
perfSONAR proposed services (see above)

Our goals for such bundles include:
        -- well documented
        -- easy to install
        -- well tuned for performance
        -- bug-free / well-tested
        -- supported

PerfSONAR Release
=================

We agreed to urge individual services to start doing individual service 
releases as soon
they are ready.

"Ready" is defined by the individual service developers, but should take into 
a account:
        -- Availability of major new functionality and/or important bug fixes
        -- Adherence to the defintion of a perfSONAR proposed service or 
perfSONAR service
        -- Good faith effort to meet bundle release goals.

We agreed as a group (ESnet, Internet2, GEANT2 JRA1, RNP) to put out a "new 
perfSONAR
Bundle release" around the end of the year.

Regarding the release management process:
        -- We agreed that Loukik Kudarimoti would be the lead release 
engineer for this release.
        -- We agreed that Loukik (with Nicolas and Szymon) could decide on 
whether to
           modify the release engineering process or not. (They have since 
decided to do so.)
        -- We agreed that the existing release management team had strong 
reservations
           about switching to ANT over the current PERL-based process.
        -- We agreed that the shared goal was to move to existing package 
management solutions
           (not written by us) in order to make the installation process 
simple and
           familiar to sysadmins in the US, Brazil, and Europe.
        -- We agreed to discuss as a group what the release should be called. 
Issues
           include:
                -- Is it a "perfSONAR", a "ESnet-G2JRA1-Internet2-RNP", or a 
"G2JRA1"
                   release?
                -- Should the version # go to 1.1 or 2.0 or something else 
entirely?
                   Keep in mind the version number of the schema.

Goal: We agreed to try to work towards a perfSONAR x.x release as our next 
release.

We agreed that the release MUST include:

1) Centralized LS
2) RRA MA

We agreed that the release STRONGLY SHOULD include

3) Multi-LS

We agreed that the release MIGHT (in rough priority order) include

4) SQL MA
5) CLI MP
6) Layer 2 Status MA
7) BWCTL MP/MA
8) HADES MP/MA
9) SSH / Telnet MP