On 12/7/2018 4:00 AM, Harald Barth wrote: > > Hi Jeff, hi David! > > Has it been 17 years? Well, we are all getting - mature ;-) > > Obviously a file system is ready for use if it's old enough to buy > liquor (which difffers a little between countries). > >> When opening a support case please specify: >> >> Product: Red Hat Enterprise Linux >> Version: 8.0 Beta >> Case Type: Feature / Enhancement Request >> Hostname: hostname of the system on which RHEL8 beta was installed > > We have a hen and egg problem here: Why would I install 8.0b on > <whatever hostname> if it does not have kafs? Install a Fedora > test, sure, but RHEL 8.0b?
You need to register for and install the RHEL 8.0 Beta to be eligible to submit a feature / enhancement request. RHEL 8.0 Beta does not include kafs. Hence the need to request its inclusion as a feature request. >> If you are eligible, please attempt to open a support request by >> December 11th. > > 3 workdays. Optimistic. If you personally are unable to do so, then you won't. However, others have already submitted feature requests in response to this thread. To them the community owes thanks. The more requests that are received the better. >> As part of the Linux kernel source tree, kafs is indirectly supported by >> the entire Linux kernel development community. All of the automated >> testing performed against the mainline kernel is also performed against >> kafs. > > But the automated testing does probably not (yet) fetch a single file > from an AFS server. The automated testing performed by Red Hat doesn't as yet perform such testing but AuriStor's testing does. > Testing that requires infrastructure is a lot of work to > automate. Not true. At the 2015 AFSBPW Marc Dionne presented on AuriStor's docker based infrastructure for automated testing of multi-server cells including clients. http://workshop.openafs.org/afsbpw15/talks/friday/dionne-docker.pdf Since that time AuriStor has added live testing of kernel modules. Each run currently performs approximately 7000 individual tests. > Sorry, I may sound much more pessimistic here than I am actually are. > This _might_ fly. I wish.... :-) There is ample reason to be pessimistic Its really easy for Fedora Core and Debian to ship kernels built with kafs and AF_RXRPC enabled because there are no guarantees. I believe that if Red Hat enables kafs in Enterprise Linux there are substantial costs and commitments associated with that decision: * Documentation of AFS and AuriStorFS capabilities and limitations not only as a filesystem but with regards to interactions with other Red Hat supported components. * Training for system engineers. * Integration of AFS and AuriStorFS support into other Red Hat supported technologies * Development of Certification and Training programs for partners. * A ten year commitment to develop, maintain and fix kafs and AF_RXRPC * Development and maintenance of test infrastructure. The truth is that the costs associated with code development is a small component of the total costs. As such Red Hat must be convinced that inclusion of kafs and AF_RXRPC will provide functional capabilities to end users that cannot be achieved via other Red Hat supported storage technologies; and that supporting kafs and AF_RXRPC will provide a long-term benefit to their bottom line. That said, I believe a case can be made by the members of this community. In 2001 Red Hat couldn't support AFS because of GPL vs IPL10 conflicts. Now that kafs is available, it becomes possible for Red Hat to do so. Its up to all OpenAFS and AuriStorFS end user organizations to make the case. Good luck to all. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
