Development Wish List / Road Map for OpenAFS

In its ten plus years as an open source project, OpenAFS has established AFS as an open source success stories.  OpenAFS provides clients for all of the major operating system distributions and servers on all UNIX/Linux variants.  Even so, there is still a great deal that must be finished in order for AFS to acheive first class status on MacOS X and Microsoft Windows.

The work to be accomplished on OpenAFS falls into six broad categories:

It is the goal of the OpenAFS Elders to raise resources from the OpenAFS Community and others to successfully implement all of these functions over the next three to five years.

An Implementation and Release Schedule is provided at the end of the page.

A note about the estimates provided on this page.  For many of the projects the Gatekeepers have designs, partially completed work, or even fully implemented systems.  The estimates that are provided is the time necessary to complete the project and/or integrate it into a standard release of OpenAFS.

1. Core Client Functionality

Core client functionality encompasses the AFS cache manager, file system interfaces, pioctl interfaces, and credential management.

Microsoft Windows:

The Microsoft Windows client has received significant attention over the last four years.  It is a fully functional client that works on all Microsoft Windows releases from Windows 2000 SP4 through Windows Vista and Server 2008.  For a summary, see the OpenAFS for Windows Status Report.  Still, there are a number of deficiencies that adversely impact the ability of end users to use AFS to its full existing potential.

All UNIX platforms:

MacOS X:

Linux:

Solaris:

BSD:

New Client Platforms:

There is a growing demand for pervasive access to data from handset devices.  Clients for Symbian S60, Windows Mobile, Apple's iOS, OpenHandsetAlliance (aka Android), and Nokia/Intel Maemo/Meego devices will be critical in the years to come.

All Platforms:

2. Human Interfaces

There have been many discussions about how hard AFS is to use, how end users don't want AFS and really want a WebDAV solution.   What do those statements really mean?  First, AFS isn't any harder to use than any other authenticated file system from the perspective of end users.  If a user has an "encrypted" local disk she has to authenticate herself by providing her password.  With the single sign-on solutions available for OpenAFS there isn't much reason for users today to be running without tokens when they have network access.  Second, the statement that end users don't want AFS (as opposed to some other centralize storage solution) really makes no sense.  End users don't ask for technologies, they ask for functionality.  If a user wants centralized storage then the user wants centralized storage. 

Users describe their desires using the technologies that are most familiar to them which today most often means Windows Shares (CIFS) and Browser based services.  Why?  Because those are the technologies the user is presented on his or her operating system's desktop.  The vast majority of daily users are uncomfortable with command-line operations.  Improving the ease of use of AFS can be achieved by providing tighter integration with the operating system desktop environment. 

Microsoft Windows:

The Secure Endpoints Inc. OpenAFS Windows Road Map web page provides an number of mock ups of Explorer Shell extensions that can be used to not only make AFS more accessible to end users but also significantly improve its ease of use.  By making the Explorer Shell AFS aware, users will be more comfortable using it. No longer will users have to use command line techniques to access AFS and manage its contents and metadata.

One of the most important ideas that was the result of discussions with Stanford University's Help Desk staff is the concept of Custom Name Spaces.  On Microsoft Windows a Name Space is a virtual folder that appears as part of the Explorer Shell.  The objects "My Computer", "My Documents", "Control Panel", My Network Places", "My Sharing Folders", etc. are all name spaces.  Stanford University has been shipping for many years variations of an application now called "Stanford Desktop Tools".  One of the features of SDT is the ability to search for classes, users, departments, and projects and map a drive letter to the associated AFS volume.  Another feature is the ability to quickly map a drive letter to "my home directory".  A final feature is the most recently used volume list.

With Name Spaces, we can implement all of this functionality.  We can define a "recently used volumes list" which is always populated with the volumes the user most recently read or stored data to.  We can define a "My Stanford Home Directory" name space that always contains a shortcut to the volume associated with the user's token for the ir.stanford.edu cell.  We can also create name spaces for "Stanford Users", "Stanford Classes", "Stanford Departments", etc.  Other organizations can distribute their own AFS name spaces that represent important data that is stored in their cell.  AFS name spaces from multiple organizations can co-exist on the same system.  Since name spaces are built into the Explorer Shell they are always easily accessible to the end user because they become a part of the Desktop.

A detailed proposal describing an AFS Name Spaces implementation is available in PDF.

Users expect to find a Control Panel for Services that support per-user configuration.  For OpenAFS users can configure the behavior of the AFS Credential Provider for Network Identity Manager and their Protection Service Groups.  For more details ...

System-wide configuration of Services are performed via Microsoft Management Console plug-ins.  For more details ...

Microsoft Windows Vista User Account Control Privilege Separation.  For more details ...

MacOS X:

Apple doesn't permit the same degree of customization of the Finder as Microsoft does for the Explorer Shell.  However, the Finder can be customized with an AFS virtual folder and AFS context menus. Likewise, certain other graphical interfaces which will become available in Leopard provide opportunities for customization to ease use of AFS.

3. AFS3 Protocol Feature Enhancements

In order for AFS to be treated as a first class file system for MacOS X and Microsoft Windows it must gain the following functionality:

4. Server Enhancements and Management Tools

All Platforms

Microsoft Windows

Once AFS is capable of being used as a first class file system for Microsoft Windows clients it will make sense to support the AFS servers on the Windows Server platform as there are a large number of Microsoft Windows only IT organizations that do not have the expertise to manage UNIX/Linux systems.  The servers are mostly there already.  There is work that needs to be done on the NTFS Namei implementation and there needs to be much better integration with power management, plug-n-play networking, and Windows Event Logging.

Of course if you want to host services on Windows, you must provide a Microsoft Management Console plug-in to manage them.

For more details ...

Estimate: 4 to 6 weeks

5. High Performance Computing Extensions

6. Miscellaneous

7. Documentation

Implementation and Schedule

The implementation schedule for these projects is entirely dependent upon resource availability.  Please send inquiries, comments, and offers of support to openafs-gatekeepers@openafs.org. Where external contributors have promised contributions, they are included, as are timelines when those are provided.   The following release schedule is subject to change.

1.4.15

The next release in the previous stable series for UNIX is expected before December 2011.  This release will correct implementation defects and will most likely be the last release in the 1.4 series.

1.6.8

The 1.6 series is the current stable series for UNIX and the last stable series for Microsoft Windows without a native IFS implementation. 
1.6.8 is the next release in the series and is expected April 2014.

1.7

The 1.7 series is the development branch for the Windows IFS implementation.  The first release on this branch was announced on 15 Sept 2011.  Subsequent releases are expected every two to four weeks until the code enters maintenance mode after two or three months.

1.8

The 1.8 series will become the first stable release of OpenAFS to include the Windows IFS implementation.  No other new features will be added to 1.8.

1.9

The 1.9 series will replace the 1.5 series as the experimental release series.  1.9 releases will begin shortly after the 1.7 series has the Windows IFS implementation committed.  Major new features will be integrated into 1.9 releases in preparation for the 1.10 stable release. 

2.0

The 2.0 series will replace the 1.6 and 1.8 series as the stable release series for UNIX and Microsoft Windows.  The 2.0 series are scheduled to include the rxgk security class including Kerberos v5, RxUDP performance improvements, PTS authentication name extensions, and extended callbacks.