[OpenAFS] Proposal: OpenAFS foundation to develop AFS server
appliance
Jeffrey Altman
jaltman@your-file-system.com
Sat, 01 Sep 2012 13:27:35 -0400
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig42415C37D26E82FF095567C2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
[Removing afs3-standardization because the subject is OpenAFS specific.]
On 9/1/2012 12:43 PM, Troy Benjegerdes wrote:
> I believe the proactive case here would be to create an OpenAFS foundat=
ion
> with the charter to work with storage hardware vendors to offer and mar=
ket
> storage hardware with the AFS server software pre-installed, in the sam=
e
> way that NFS and CIFS servers are already embedded in the storage produ=
ct
> hardware offering.
>=20
> Places like Your-File-System could then offer value-added upgrades to t=
he
> base embedded OpenAFS on the storage appliance.
>=20
> I think we all get so tied up in the technical aspects sometimes we for=
get
> that it is *sales and marketing* that keeps people buying crap like NFS=
> and CIFS.
End user organizations have over the last decade asked their storage
vendors to integrate AFS services into the storage products they
purchase. The answer has consistently been 'not interested'.
Up until 2005, some storage vendors had representation on the OpenAFS
Elders as a result of individual members changing employers. The
perspective of these representatives was that AFS3 should be supplanted
by NFSv4 and the role of OpenAFS should be to provide transition paths
for a conversion. As a result, those Elders were asked to resign given
the inherent conflicts of interest.
The Elders have engaged in discussions with the major operating system
vendors over the years as well. Those discussions inevitably broke down
because AFS3 did not satisfy the needs of a First Class file system.
(No Ext. Attributes, no alt data streams, no byte range locking, no
mandatory locking, directory limitations, etc.)
Given the current state of the protocol, the questions surrounding the
AFS trademarks, the large investments in NFSv4 and CIFS, and the
relatively small market of the AFS installed base, there is no interest
in adding AFS3 protocol support to existing hardware storage products.
Hardware vendors will only be interested in integrating a product that
addresses the needs of Stanford University. Of course, that is what Your
File System, Inc. is building.
I have said for years that continued use of any enterprise
infrastructure protocol or product requires the confidence that the
technology can support a ten year window of devices. Five years
backwards and five years ahead. Of course it is not possible to predict
what things will look like five years from now so decisions must be made
based upon having faith that the technology will continue to be
supported on all required platforms over that time period.
It is quite clear to me that the CIOs and CTOs of many end user
organizations no longer believe that OpenAFS can provide the required
functionality in five years time. Since the transition time to execute
infrastructure platform changes is three to five years, the decision to
begin the process of migrating is being made at an increasing number of
sites.
Its all about momentum. Marketing is important in that it can affect
opinions that drive momentum. But in the end, what is most important is
delivering the features and functionality that is deemed to be mandatory
or demonstrating the ability to do so. In 2007, when Derrick Brashear
and I presented OpenAFS at the Spring HEPix conference, we heard that
message loud and clear from those in attendance.
In my opinion, it is not necessarily too late for an OpenAFS Foundation.
It is too late for an OpenAFS Foundation to market the existing
implementation.
Jeffrey Altman
--------------enig42415C37D26E82FF095567C2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJQQkWHAAoJENxm1CNJffh40DMH/3iQZ093XzNYsVjhu+wh6xz6
w7hkha2MhcKPEvrD3/FcKcb5tUcDdjv+fTK8Y8p3w75Q0qsPV8sRGtmTLFEXtvpb
vIUiEQKgQyKsVxpR1+OrW0V8Py1qqwVydtwaIInNuZxny1d8+zoOwBVSRtSW3OTT
u3HtgMCDwUMKaaI772FV+zVr37O0QNL3eaklTF9ZLvzDNk0ExIH+0y5BASuQoNJG
PyJH78x2lR2l/Hml+WtTmZluYWddqbsBKBf+KRdsb5+/2QlL1SerhwJdRxJhkXg1
Xo0pzhNm+/5Z5yYeM+CthJsf0QyhfbxLvDIOYUVEvWubGjWwFrCfgaBJfshcI1E=
=gpew
-----END PGP SIGNATURE-----
--------------enig42415C37D26E82FF095567C2--