DICE development projects - 3s_Stalled

Redevelop School Equipment inventory

boss — Fri, 25 Jan 2013 15:46:29 +0000

Project ID:

269

Current stage:

3s_Stalled

Manager:

ascobie

Unit:

compexec

What:

Description: Design and implement a new School equipment inventory.

Deliverables:

Why:

Customer:

Case statement: The current inventory system does not meet all our requirements and there is concern that tracking machines has now become unreliable. This is particularly the case for self-managed machines. We are not able to easily answer fundamental inventory questions - this is a particular problem for planning expenditure and machine allocation.

A previous project reviewed the existing system. It had been hoped that this project would identify some simple fixes to the existing system, but unfortunately the conclusion was that the base inventory schema was sufficiently flawed that many problems could simply not be fixed. Basically, the system was not designed to cater for self-managed machines.

It is widely accepted that a complete redesign is required. It may well be possible to re-use some components of the existing system.

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: 9 weeks effort in total.

Plan:

Check what other schools are using to inventory equipment
Design (2 weeks)
1. Sketch architecture
2. Design schema
3. Decide on information flow between information sources/sinks
4. Consider whether software inventory could be easily added as a later project
5. Consult
6. Determine how much of Theon can be used (querying/editing/reports)
7. Sketch design of :
  1. inventory editing/querying tools (invedit/invquery)
  2. order editing (rfe orders)
  3. MAC loading
  4. LCFG conduits
  5. client machine conduit (clientreport)
  6. switchdb conduit (switchtoinfdb)
  7. Web reports
8. Consider which existing data to migrate, and how.
9. Consult
Implement (4 weeks)
1. Add schema to Theon and create tables
2. Create test data and load into tables
3. Implement inventory query tool
4. Implement order editing code
5. Implement MAC loading conduit
6. Implement client machine conduit
7. Implement switchdb conduit
8. Implement LCFG conduits
9. Implement inventory edit tool
10. Implement web reports
11. Test against test data
Documentation and training (1 week)
Migrate data (2 weeks)

Other:

Home page:
home page on wiki

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Streaming Media Service Requirements

boss — Fri, 25 Jan 2013 15:46:27 +0000

Project ID:

259

Current stage:

3s_Stalled

Manager:

roger

Unit:

services-unit

What:

Description: Investigate the needs of users and the requirements necessary to provide an operational Streaming Media service, as a precursor to implementation (Project 227).

Deliverables: A clarification of what is required by users of a Streaming Media service, an assessment of viability, and a list of functional requirements that would need to be implemented.

Why:

Customer:

Case statement: Though there is a central, IS, provided service, which would continue to be used for larger scale events. Something smaller and simpler for use in-house would be useful - and in order to implement this, a functional specification is required.

When:

Status:

Timescales: estimate 1 week.

Priority: Not enormously high - but it does, in theory, block project 227.

Time:

How:

Proposal: We need to know what were committing ourselves to in implementing a Streaming Media service, what's feasible, and how this sits with what users are actually asking for.

Resources:

Plan:

Establish current and prospective user base.
Consult with user base to establish current usage and performance.
Investigate current levels of service provided in-house and by IS.
Establish required functionality, based on user feedback. Clarify and refine as appropriate.
Draft initial requirements list and solicit user feedback.
Prepare final requirements list.

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Absence Reporting Management

boss — Fri, 25 Jan 2013 15:46:26 +0000

Project ID:

257

Current stage:

3s_Stalled

Manager:

Unit:

mp-unit

What:

Description: A combination of factors; external compliance via UKBA and HR legislation or compliance with US accounting rules necessitate the need to update absence management procedures within Informatics. On the flipside the intention is to introduce the lightest touch possible reporting and management requirements.

One option is to introduce a webform to simplify absence reporting. An example from another School would be https://www.wiki.ed.ac.uk/display/SBSIntranet/Home+Page in School of Biological Sciences (but note secure access permissions to site). This tool allows an SBS staff member to securely notify HR of absence.

Overall requirements

a need to scope remit of webform, noting that the simpler the form the better
consideration of linked email notifications (to whom ?, saying what ?)
identify website location and login permissions as a submitter
a need to verify all against technical contraints and Data Protection Act.
data access to InfHR and then Oracle.
webform construction and data repository.

Deliverables: Effectively a web form for recording absence. Something/somewhere to hold the data submitted via the web form.

Why:

Customer: Staff

Case statement: Legislative requirement to do something.

When:

Status:

Timescales: Required as soon as possible as current position is non-compliant with University policy or external requirements.

Priority: See timescales.

Time:

How:

Proposal: See plan.

Resources:

Plan: Initially just scope requirements and propose an implementation. Consider whether a standard WebMark form (which can be fed with external data and can send results by email) may be the quickest option.

Other:

Dependencies: Unclear if there are dependencies on any external data to drive web form and where to send/store the output of the web form.

Risks: Needs to be available very soon. Currently still a fuzzy requirement.

Milestones

Proposed date	Achieved date	Name	Description

Introduction of Drupal as the new commodity WCMS

boss — Fri, 25 Jan 2013 15:46:13 +0000

Project ID:

192

Current stage:

3s_Stalled

Manager:

cms

Unit:

services-unit

What:

Description: After much debate, the decision was taken to switch to using Drupal as the School's commodity WCMS. This project will handle the introduction of a full Drupal service into the school

Deliverables: A Drupal WCMS service, fully documented and managed via LCFG. An upgrade path from the current Zope/Plone WCMS may also be developed as part of this project.

Why:

Customer: School

Case statement: repeated requests from the School user base and the increasing use of Drupal within the rest of the University have lead to the decision to use Drupal as the School's commodity WCMS in future. We need to develop a service to support this decision.

When:

Status: Drupal 7 was released at the beginning of 2011

Timescales: The need to gain the appropriate knowledge of Drupal will lengthen this project. At a rough estimate:

Drupal Knowledge acquisition: 2 weeks
Implementation: 4 weeks
Documentation: 1 week

Priority: Though we have a commodity WCMS in place, we would be reluctant to create any more web sites using the existing system. This project should therefore have a fairly high priority.

Time:

How:

Proposal:

Resources: Knowledge of Drupal and Apache We should make every effort to make use of the Drupal knowledge which exists in the rest of the University.

Plan:

Other:

Dependencies: Release of Drupal 7.

Risks:

Milestones

Achieved date	Proposed date	Name	Description
2012-02-03	2012-02-03	initial test si	Set up test site for initial investigations
	2012-07-21	documentation	Produce user and system documentation
	2012-06-30	multiple sites	Decide how to handle virtual hosts (one big server or many separate servers)
	2012-06-20	module list	draw up initial module list. It may be helpful to refresh the requirements list originally generated to guide the selecton of the WCMS to aid in identifying which modules are required. Also see Biological Sciences, G.Poxon's list.
	2012-07-14	skinning	Add School/University look and feel
	2012-06-20	development env	Decide on recommended development environment. ie RPM or filesystem
	2012-07-31	package	decide on packaging of core drupal compoments. Though this is important, getting a service up and running is more important. Cross college work may do this part for us.
	2012-07-31	mod manage	decide how to do module management. Though this is important, getting a service up and running is more important. Cross college work may do this part for us.
	2012-06-20	Workflow	Decide how workflow should be handled on the new site(s)

Currently stalled. While waiting for news on central IS hosted drupal service. Feb 2013.

Prometheus: enable account lifecycle

boss — Fri, 25 Jan 2013 15:46:13 +0000

Project ID:

188

Current stage:

3s_Stalled

Manager:

toby

Unit:

inf-unit

What:

Description: Enable the account lifecycle code. This will give us the ability to properly manage the user account lifecycle so accounts can be archived and subsequently deleted. See points 4 and 15 of https://wiki.inf.ed.ac.uk/view/DICE/PrometheusTodo#Project_Completion_TODO for more details.

Deliverables: Account lifecycles

Why:

Customer:

Case statement:

When:

Status: We will not get code from sxw. We have some sketchy design. Need to decide how to proceed, but almost certainly start again almost from scratch.

Timescales:

Priority:

Time: Anything between 2-4 weeks as a very rough estimate. sxw could comment more accurately

How:

Proposal:

Resources:

Plan:

Other:

Dependencies: Depends on the "account reconciliation" project
devproj #182.

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Password strength checks

boss — Fri, 25 Jan 2013 15:46:09 +0000

Project ID:

168

Current stage:

3s_Stalled

Manager:

gdmr

Unit:

inf-unit

What:

Description:

See the note in the "plan" section below.

The April 2010 Development Meeting suggested a project which would "look at checking the strength of existing passwords on the KDC and/or checking password strength when changed on the KDC (at the moment strength checks are only made on DICE clients)."

The Operational Meeting of 22nd June 2011 subsequently returned to the subject of password security (in the context of Indicident Management), and how we can best avoid our users having weak passwords. Mention was made of a PAM module which captures passwords entered by users and flags up passwords considered weak; it was agreed that investigation of that module should be added to this project.

The project should ideally allow for the possibility of using several different types of checks, operating in and/or combinations. Whether the kadmind hooks allow for this remains to be seen, though a meta-module might do the job if it's not there natively.

Deliverables: Stronger passwords all round, making it less likely that we get burgled.

Why:

Customer: All

Case statement: Weak passwords, particularly for little-used accounts, create holes for intruders. That's not desirable, so this project aims to produce ways in which they can be avoided, or at least detected.

When:

Status:

Timescales: "It depends". A syslogging PAM module might only take a week or two to set up, but would only catch changes as they happen on DICE machines. Hooking into the kadmin daemon is likely to be a 4-week-ish job, as would be post hoc analysis of the KDC's cont

Priority:

Time:

How:

Proposal:

Resources: Depending on how the project proceeds, some code might have to run on the master KDC. Post hoc analysis could run on a slave KDC for load reasons.

Plan: NOTE: some of the previous ideas for this project have been overtaken by events. It is therefore proposed to move this project to "evaluation" in the first instance, to allow us to take stock, and to see what additional measures we might take and the implications thereof. There are therefore no milestones, nor any detailed plan, at this stage.

Other:

Dependencies: Pending completion of the upgrade-KDCs-to-SL6 project.

Risks: Breaking password-changing in some way! If we don't do it we're arguably no worse off than we are at the moment, though that's not an ideal place to be...

URL: http://www.dice.inf.ed.ac.uk/units/infrastructure/Projects/168-PWstrength/

Milestones

Proposed date	Achieved date	Name	Description

SICSA web

boss — Fri, 25 Jan 2013 15:46:08 +0000

Project ID:

163

Current stage:

3s_Stalled

Manager:

iainr

Unit:

rat-unit

What:

Description: Redevelop the "look and feel" of www.sicsa.ac.uk keeping the current content and platform (plone)

Deliverables: A new plone theme and associated graphics.

Why:

Customer: SICSA

Case statement: SICSA have requested and CEG have approved.

When:

Status: writup https://wiki.inf.ed.ac.uk/DICE/163SICSA_Web

Timescales: As soon as possible within the T2 framework

Priority: Medium

Time: 2 FTE weeks

How:

Proposal:

Resources: iainr

Plan: look for possible themes, install these on test copies of the sicsa website and hold a meeting of interested persons. Hopefully choose a theme and rework it, have a meeting to discuss results. repeat until the principals are happy with the results. Declare victory.

Other:

Dependencies: None

Risks: Possible time black hole if customer does not have a clear idea of their requirements.

Milestones

Proposed date	Achieved date	Name	Description
2010-04-01	2010-04-01	search	Look for suitable themes matching sicsa's requirements
2010-04-01	2010-04-01	createclone	Generate a number of clone copies of the sicsa website for testing
2010-04-02	2010-04-02	createtests	install each theme on a clone site and tweak graphics etc to match
2010-04-10	2010-04-10	custmeet	Meet with customers to identify best match (if any) and what changes need to be made
	2010-05-11	tweak	make changes to possible theme
	2010-04-30	approvemeet	Meet with customer to approve tweaks
	2010-05-13	implement	install the final theme on live website.
2011-03-24	2011-03-14	writeup	Writeup report
	2011-03-14	Signoff	sign off project

Replacement for VMware Server

boss — Fri, 25 Jan 2013 15:46:06 +0000

Project ID:

154

Current stage:

3s_Stalled

Manager:

ascobie

Unit:

mp-unit

What:

Description: Thanks to the Simple Server Virtualisation project we now have several dozen servers running in virtual machines, the infrastructure for which is provided by VMware Server. VMware Server is no longer being supported and needs to be run on an old version of SL5, so needs replacing urgently. Moreover, it does not support migration and replication.

Deliverables: The project will identify, and deploy, suitable technology for hosting our virtual servers for the next five, or so, years.

Why:

Customer: The School of Informatics, as user of most of the services running on current virtual servers. Other parts of the University, and organisations external to the University of Edinburgh, also use some services hosted on our virtual servers and would indirectly benefit from a more reliable and configurable virtual server hosting infrastructure.

Case statement: Several dozen of our servers run on virtual machines. These virtual machines are run using software called VMware Server. It was convenient for us to use this software as a short term measure but its suitability is degenerating from "barely adequate" to "dangerously unstable" and it has to be replaced. Among its inadequacies:

It can only be configured through a web interface. Such configuration is both time-consuming and prone to error, and is not amenable to automation with LCFG.
The software is not keeping pace with developments in the Linux kernel. It is less stable when used with the current SL5.5 kernel than with the SL5.3 kernel so we are having to hold back our VMware Server host machines at SL5.3. This is not ideal and can't be maintained for more than a few months.
It appears to have stability issues when the underlying storage platform is underperformant, but this may be the case for any virtualisation technology.
The virtual machines' serial consoles can only be accessed through the web and even then only on a strictly limited range of OS environments. We need better access to our servers' serial consoles than is provided here; quick and easy access is a considerable advantage especially in emergency situations.

IS have an established VMWare based service. This is based on the bare-metal enterprise VMware product which has a good reputation for reliability. This will shortly (Nov/Dec 2010) be opened to non IS groups. We would have to have strong reasons for not making use of this service.

When:

Status:

Timescales:

Priority: Our current VMware Server hosts are already having to be held back to outdated OS versions; this situation can only get worse. A replacement is urgently needed. This project should therefore be assigned a high priority.

Time:

How:

Proposal:

Resources:

Plan:

Produce requirements document (mandatories and desired), consulting with other COs.
Evaluate the IS service against our requirements document, including experimentation with guests.
If the IS service does not meet our mandatory requirements
1. Investigate technologies (eg KVM, Xen). Consult with other CSE schools.
2. Evaluate the technologies against our requirements document and produce a report summarising findings.
3. Choose a technology
4. Develop tools to deploy chosen technology - simple virtualisation
5. Deploy - simple virtualisation
6. Migrate services from VM guests on current service to VM guests on the new service
7. Enhance tools to support live migration of guests
8. Deploy - migration

Other:

Dependencies:

Risks: Several dozen servers and services already use our virtual server hosting, and a less inadequate service might attract many more. These virtual hosts run a wide variety of services for the School of Informatics and beyond. Any replacement would need to be utterly dependable or put these services at risk.

Milestones

Proposed date	Achieved date	Name	Description

Collaborative LaTeX System

boss — Fri, 25 Jan 2013 15:45:48 +0000

Project ID:

Current stage:

3s_Stalled

Manager:

timc

Unit:

rat-unit

What:

Description: The Collaborative LaTeX system allows end users to create and manage their
own subversion repositories for LaTeX documents (primarily ACLs) with support
for external collaborators (via iFriend). The backend manages the LaTeX build
process, also creating change documents and can mark up merge conflicts.
Currently a prototype service this project is to (re)develop the existing prototype service into a full production service.

Deliverables: A production service with full administration documentation and tested recovery procedures.

Why:

Customer: CSTR/HCRC (Steve Renals, Simon King & Jean Carletta)

Case statement: The existing service at https://coltex.inf.ed.ac.uk has been working very well for over six months - a number of large collaborative documents have been developed using it. However more people have requested accounts, users in other institutes have expressed interest in it and existing users now rely on it leading up to grant submission deadlines so it is no longer practical to maintain it as a prototype service. While the existing service is stable and backed up and the structural design meets user requirements the client and back end code was quickly written to prove the design rather than to meet quality coding standards and needs to be revisited. The backups are also currently only done daily using existing mirroring technology whereas it would be better to implement an svnsync technology to live sync repository commits as they happen (on a large collaborative work there could be many changes each day and recovery to the previous days state would be unsatisfactory, particularly when there are deadlines to be met). There is currently no technical documentation on the design and administration. Loose recovery procedures have been tested but need to be more fully documented. While almost everything is contained in LCFG and RPM, the base initial authorization is not, and needs to be LCFGified to allow support to add/remove accounts.

When:

Status:

Timescales: To happen over the next six months.

Priority: Medium - existing service is working fine.

Time: 4 FTE weeks.

How:

Proposal:

Acquire and move onto better hardware.
Implement an svnsync backup mechanism.
Document design and do a technical presentation.
Document administrative procedures for support.
LCFGify basic authorization for support.
Re-design and re-code client command script.
Re-design and re-code backend scripts (possibly using a central daemon).
Re-visit repository hierarchy design (now we have a lot more ...)
Address other minor outstanding bugs/features on FAQ and TODO lists

Resources: Hardware - currently runs on an old desktop with local non-RAID disk for storage, ideally roll down a newer rack based server with RAID.

Plan: See proposal for list of required work.

Other:

Dependencies: Uses LCFG "subversion-server.h", "apacheconf-2.h", "x509-client.h", "apacheconf-ssl.h", "apacheconf-cosign.h", "apacheconf-krb5.h", "rsync.h", "localaccounts.h" and "ipfilter.h" headers - changes to these may break the service.

Risks: Current code base is in Python and Bash. Python preferred by existing end-users. Limited Python experience across CO community (although beneficial to gain some).

Existing design may not scale.

Milestones

Proposed date	Achieved date	Name	Description
	2009-04-15	Hardware	Acquire and move onto better hardware, in reality onto a virtual server. Assumes server hardware will be available in good time to meet this milestone (also to coincide with move out of AT).
	2009-05-30	Backup	Implement an svnsync backup/redundancy mechanism. Serving two purposes - backup to last transaction during the day and a way to migrate between virtual servers to provide redundancy in the event of hardware failure.
	2009-04-30	Tutorial	Add a "getting started" guide primarily aimed at external users to supplement the existing documentation.
	2009-04-30	Op Docs	Document system operationally, including upgrades, migration, disaster recovery, etc.
2009-05-08	2009-04-30	Authorization	Convert basic authorization to use LCFG and roles/capabilities.
	2009-04-30	Support Docs	Document account creation process for support.
2008-12-31	2009-01-31	Repos ACLs	Add ACL control onto administrative repository.
	2009-06-30	Repos Struct	Re-structure repository hierarchy.
2009-05-01	2009-04-30	Design Talk	Document design and do a technical presentation.
	2009-07-31	Redo Client	Re-design and re-code client command script.
	2009-07-31	Redo Backend	Re-design and re-code backend scripts (possibly using a central daemon).
	2009-06-30	Bug List	Minor bug fixes and feature enhancements on FAQ/TODO.
	2009-07-31	RPM	Replace Subversion live export with RPM managed distribution.

DICE client LDAP configuration

boss — Fri, 25 Jan 2013 15:45:45 +0000

Project ID:

Current stage:

3s_Stalled

Manager:

toby

Unit:

inf-unit

What:

Description: Investigation into DICE client LDAP configuration, to replace our existing home grown technology.

Deliverables: Recommendations for DICE client LDAP configuration, including LCFG configuration. Also, fully document all conclusions from investigations.

Why:

Customer: All

Case statement: Initially, see this case statement for the "OpenLDAP Replication and Server Configuration" project, which this project has been spun off from. This project is only concerned with the client-side, specifically ways to replace our technology, in which all DICE clients run a full LDAP server. This approach has proven unreliable, particularly where clients run memory-intensive jobs. It is a pre-requisite of this project that any connection between clients and remote LDAP servers be secured. Since the original project was proposed, new techniques have arisen. In particular, there are three candidate approaches to providing secure client-side LDAP which require detailed investigation:

OpenLDAP proxycaching (using the openldap ldap backend and pcache overlays), which provide proxying to a remote LDAP server, with local caching (or not) of pre-configured queries.
nss_ldap - using kerberos-authenticated connections to a remote server
nss_ldapd - a fork of nss_ldap to address certain issues.

When:

Status:

17/07/09: As discussed at the July development meeting, this project is to be put into a stalled state, although I will continue to monitor developments and run test clients. Unfortunately it just hasn't proved stable enough to consider deploying and debugging efforts have reached somewhat of a dead end.
05/03/09: As discussed at March development meeting, push back milestones to allow time for debugging/bug fixing/assessment for 2.4
03/03/09: See blog for latest. We need to decide now whether the project should be stalled, or whether another milestone for 2.4 testing is added.
18/12/08: Marked various milestones as done, as discussed at last devproj meeting, amended date for new proxy-crashes milestone to give myself a bit more time (factoring in Christmas break), amended subsequent milestones accordingly...
08/12/08: Latest project stuff here. Comments welcome.
08/12/08: 2.4 - proxycache now seems stable, but ITS#5756 is a problem.
08/12/08: server testing - 2 servers currently being used - load so far is
minimal, but needs more testing with condor and also beowulf. It is ultimately our intention to run the LDAP slaves with extremely minimal logging (this vastly improves performance on a busy server). We will keep logging for the moment while testing is being done.
08/12/08: testing - proxycaching is currently running on all SL5 develop
machines, and in two student labs - AT-4.12 and AT-5-cl-s. 122 LCFG
profiles in total. Condor only recently added to labs and seems to
have increased number of crashes - this requires investigation - added
milestone.
06/11/08: I'm going to attempt to maintain a blog to discuss work on this project (and other ldap things)
26/08/08: Milestones revised as agreed at August development meeting
26/08/08: Work has been substantially delayed on this project due mainly to the
move to the Forum, but also because of SL5 server upgrades, exams in
labs and upgrades to SL5 of lab machines (as all desktops are moving
to SL5, there is little point in testing under anything else). Annual leave in September is also contributing to the delay.; The current focus will be to expand testing in labs, on beowulf
clusters and on some desktop machines.
26/08/08: During the last year, the OpenLDAP project has released version 2.4.
This has now become the recommended "stable" release. It is important
that we test and evaluate this version of OpenLDAP as well as the
latest 2.3 version. The versions we are currently using for testing
are 2.3.43 and 2.4.11. I have added a milestone to evaluate 2.4.
Briefly, the pros and cons of 2.4 are... Pros: contains functionality
that we would like, it is the focus for new development, it will be
better supported than 2.3. Cons: relatively untested in our
environment when compared to 2.3, judging by the bugs we've uncovered,
slapo-pcache is perhaps not tested much by the community. Ultimately
we will almost certainly move to 2.4 for all openldap use, the main
question is when and whether we do it for this project.; Bug reports have been submitted to the openldap project for problems
we have seen when using the pcache overlay with Openldap 2.4. See
openldap href="http://www.openldap.org/its/index.cgi?findid=5546">ITS 5546
and ITS
5665 for further information.
31/03/08: A bug report was submitted to the openldap project detailing the intermittent fault we were seeing - see openldap ITS 5404 for further information. Following this, a patch was produced and has been in testing since 10/03 with no recurrence of problem.
08/11/07: We have discovered an occasional problem with proxy-caching that requires further investigation before we implement it more widely.
06/11/07: Initial conclusions on the various client technologies
01/10/07: Following discussions with George concerning the timescales of this project, we have set an initial milestone for the November development meeting for conclusions on the various client technologies being tested. Subsequent milestones will be set following this.
14/09/07: Initial project proposal.

Timescales: We would expect the project to be completed by the end of the calendar year, in the worst case. Certain factors should be considered - particularly the relative open-endedness of testing and debugging. Also, expected paternity leave, etc. in November.

Priority: High priority.

Time:

How:

Proposal:

Resources: Difficult to quantify. A large amount of testing of various configurations will be required, which may involve a lot of 'calendar time' without necessarily requiring a lot of person-time, i.e. leaving a configuration in place in a test-cluster for testing under real-world conditions. Requires experience of OpenLDAP and nss_ldap, as well as general Linux and C debugging skills.

Plan:

Evaluate and test OpenLDAP proxy-caching and proxy-no-caching solutions.
Evaluate and test nss_ldap with kerberos authentication
Evaluate and test nss_ldapd
Conclusions on best solution
LCFG configuration for best solution
Document conclusions and recommendations

Note that the first three items can effectively run in parallel

Other:

Dependencies: None

Risks:

Milestones

Proposed date	Achieved date	Name	Description
2007-11-06	2007-11-07	initial_conclus	Initial conclusions on the various client technologies
2008-03-31	2008-03-31	proxy-debug	Investigate occasional problem with proxy-caching and proxy-nocaching
2008-11-30	2008-11-30	proxy-moretest	expand pool of testing machines to further test client-side operation
2008-11-30	2008-11-30	proxy-servertes	assess server load generated by client-side testing
2009-02-11	2009-02-28	proxy-meeting	inf-unit meeting to discuss recommendations
	2009-07-31	proxy-recommend	produce recommendations for dice ldap client configuration
2008-11-30	2008-11-30	proxy-2.4test	test openldap version 2.4
2009-02-11	2009-02-15	proxy-crashes	Investigate slapd crashes
	2009-06-30	proxy-2.4morete	More testing with openldap 2.4 to debug, file bug reports and assess stability/reliability.