PS4.0 suggested improvements
From GEANT2-JRA1 Wiki
The list below is the outcome from a brainstorm on the new features that should be added for perfSONAR 4.0 (scheduled in summer time) or for intermediate 3.x releases (for lighter functionalities).
The questions asked where:
- What functionalities in pS 4.0?
- What should be improved over pS 3.0?
- What are the pending points?
I classified roughly the answers in two categories,
- the external functionalities that the user/deployer will benefit of and
- the development considerations
Those functionalities will be submitted to two doodle pools:
- the first on will target the first category. The deployers/users will express their preferences
- the second category will be voted for by the developers/testers
Contents |
[edit]
Users functionalities
- Feature: Authorization (of course!)
-
( all the services to register to the LS the hostname list of the router to which they are connected). - AH, DM
-
(generalized from "Utilisation categories (using colors instead of values)") - AH
- Feature: Performances improvements (RRD MA, base) - RL
- Feature: API to allow users to build their own visualisation - NS
- Feature: Virtual server in a CD you load
- Feature: Self-diagnosis (Service Support + Monthly Reports) - SD
- Feature: Network Link Status Tool - TR for NOC (APM)
- Documentation: explain the benefits to the PERT (what can I do, alert, troubleshooting, etc)
[edit]
Deployers functionalities
- Upgrade procedures - CW
- Get rid of the URLs with versions - CW
- RPMs - CW, GC, SD
- Feature: Test-suite for after the installation within an NREN: functional test, stress tests (through web-interface), what happens to the service or to the router.
- Feature: Jetty-style based system: everything is a package, you can start and stop it. (for all services) - CW
- Feature: admin web=page - SD
[edit]
Developers functionalities
- Move away from Axis v1 because of issue with SAML. Keep it in mind. (move to something else?) - CR
- Move away from Axis v1 for performances reasons - MG
- Move to java 1.6 - MG
- Protocol documentation: Balance between flexibility of the schema and define entities (string is not helpful, proper specification is required : semantics) - Functional testers, Visualisation developers, Web-services developesr
- Schema evolution: Timestamps and data types (schema quite flexible and they are defined outside the schema – proper specification of the features that should be implemented) - NJ
- Schema evolution: nmtime specification - RL
- Schema evolution: URL as result code - I2
- Schema evolution : Support for SA6 measurements (schema definition) - MG for SA6
- Schema evolution: Error codes not documented (doc all over the place)
- Organisation: define a development process - LK, NS
- Cleaning the code (standardise the error codes, information to be registered to the LS has to be made more consistent)
- New service: Transformation service for resolution (client need 30 min resolution and the service is of 1min)
- New service: Resource protection - JR
- Feature: local Resource protection on a web-service
- Feature: LS registration protocol extension (keepalives-deregistration) - MG
- Documentation enhancements : schema not complete – semantics (rnc files to be complete)
- Perfsonar base jar and nm-wg jar to possibly be re-written (no maintenance)
- Authorisation
- performances improvements
[edit]
Features under development
- Feature: Multi-domain LS (3.0 or 3.1?)
- Feature: Authorization (of course!)
- RPMs
[edit]
Information
- The change name
- The product(s) to be changed
- The change expected benefits to the users
- High level specification of the changes / drawing of the visualisation / inter-action scenarios drawing and explanations
[edit]
Feature/Change description template
[edit]
Feature/Change Title
[edit]
Feature/Change Description
This section provides high level information about the feature / change and explains the rational behind the request.
- Choose between one of the followin angles to introduce the feature:
- Problem Statement : Describe what the problem is or what is missing or
- Feature Description : Describe what the feature does. You can also point to best practices or examples of what you would like to get (give the specific URL).
- Benefits to the users: Describe the expected benefit for the user(s) (or the benefit for the developers, testes in case this is related to a procedure or an internal change e.g. to the protocol)
- Priority : priority for the feature/change from the point of view of the user
- High : it is vital for the MDM service, for the service adoption or for the user utilisation, breakthrough feature that will increase the utilisation of the service, major flaw to address
- Medium : it is an important change for the user, for the service or for the serivce adoption, will make the life easier to the user
- Low : Nice to have
- Products : list the products on which the new feature should be integrated
[edit]
Feature/Changes Specification
This section provides a high level specification of the feature/change. This description is used to assess the amount of work and coordination required and to schedule it.
- Describe what change should occur to have the feature/change implemented. Indicate the constrains they may be.
- If you describe it for a visualisation, it is best to provide a drawing (example of a new view, example of change to an existing tool) of what you expect or describe the inter-action between the user and the visualisation (example).
- In case of a new feature that requires inter-action between different tools (web-services and/or visualisations), indicate the tools involved, the actions made by each tools, the information required, the inter-actions between tools (including the inforamtion flow) and the high level changes within the tools (example - draft)
- If this is related to a document (process or documentation), indicate what should change and indicate how you would like it to be insteand of the current version (a proposal).
