Skip to end of banner Go to start of banner

Developer workshop Sept 2012 - Notes

Skip to end of metadata

Date: 21st Sept 2012
Time: Start 09:30 CEST
Location: NLNet Labs, NL

OpenDNSSEC Company Update (Patrik)
ACTIONS from last OAB meeting affecting dev team
- (Jakob) - Communicate 1.4 is a major change (blog/website)
  - For the 1.4 release generate a 'friendly' release statement with much more info than the normal release announcement.
- (Sion) - Establish 'bad' and 'acceptable' value for memory usage (ldns issue)
  - Results of discussion sent to Wilhem. Outcome was BIND has x3 or x4 fold increase (memory vs. zone size) which is just acceptable but more than that is not. ODS has roughly x8 fold increase. NLnet Labs are working on a solution but it is not clear if it should be in ODS or ldsn. This is a significant effort so committing to it would probably require board involvement. The targets are not clear yet either. Jerry does have a patch to reduce memory but this is not production ready. Best guess is that this would give 25-30% improvement. We note there is also an issue with signing time increasing over time.... (SIDN). Also raised that large memory usage is an issue for virtual machines.
  - ACTION: Generate first draft of page to describe benchmark setups and systems usage.
ACTIONS from the last developer workshop:
- Improve requirement handling
  - For existing requirements this feeds into the more general issue with regression testing coverage.
- Memory issues (ldns)

After a discussion there was agreement that more flexibility in the roadmap would be good for users. Large releases make planning hard and delays easy The development team would like the option to release smaller releases more frequently e.g. break up the 2.1 release into several releases. Consider having the development team make recommendations about the releases based on when individual features are ready for the board to review?? (Note: Need to communicate releases early to maintainers.)
Benchmarking is needed on 2.0. Performance target for 2.0 is currently quite vague. Need to choose our benchmark carefully and in detail.
- ACTION: Need to look at our competitors (e.g. PowerDNS) and see how we can compare on performance and functionality. Look at opensource options and document this.
- ACTION: Need benchmarks vs 1.4.
- ACTION: Need more information from the user community to set a target - but how do we get this?
Q for the OAB: Where does work on memory usage come in the roadmap (before DB adaptor)?
Are there simple things we can do to improve critical logging. Matthijs proposes a 1 line log as a summary of the signing result. Sion mentions Nominet have a list of 'ciritcal' logs that there monitoring system uses.

Goals, obstacles, competitors - what do we need to focus on?
- Regression testing/Knowledge sharing/Documentation
- Future directions: Functionality, usability, performance

Regression testing in Jenkins
- How to manage tests & gauge coverage
- Review of current framework
Performance & endurance testing to simulate production environments
- What are our benchmark cases?
User testing (alphas, betas)
- More formal e.g. separate mailing list?
  - Feeling was no separate mailing list but perhaps we should be stronger is requesting JIRA issue for bugs on development releases.
SIDN have some more resources...

Based on the various user requests and discussions (support for backup servers, parallel systems etc) the aim is to produce recommendations to OAB board about what we think should be supported in future. (If anyone wants to present something specific here - please let me know).
- No specific developments required - just better documentation (use Nominet setup as basis?).
- What do SURFNet do?

Review release assignments
- ACTION: Split the future release into 2. Screen for duplicates or issue to be closed. Screen for issues that can be collapsed into features.
- Review all new issues in every team meeting.
- Look at opening the OpenDNSSEC project up to users with restricted privileges so they can only create issue but not assign fix versions. These would then be reviewed in every team meeting.
Proposals for new stories