[KUDU-2698] Document public test artifact's built-in dependencies and other properties

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Cannot Reproduce
• Affects Version/s: 1.9.0
• Fix Version/s: NA
• Component/s: documentation, test
• Assignee: Unassigned
• Reporter: Adar Dembo
• Created: 12/Feb/19 18:47
• Updated: 03/Jun/20 18:12
• Resolved: 03/Jun/20 18:12

Description

When the public test artifact was first built, several choices were made about which Kudu dependencies it should include and which it should satisfy from the host system. We should document these choices and their trade-offs. Besides being useful for users (i.e. "which system packages do I need to install?"), it's also useful as a design doc of sorts to help future maintainers understand why some dependencies were included and others excluded. We should also document other interesting properties of the artifact, such as the fact that it is built on a very old host system to take advantage of several forward compatibility contracts belonging to excluded system dependencies (like glibc).

This came up specifically in the context of a discussion around the inclusion of libsasl2: like glibc, libsasl2 has good forward compatibility so we could safely rely on the host system's copy. Not to mention that libsasl2 is a security library (we generally shouldn't ship these), and excluding it would obviate the need for our special sasl modules handling. But, one of the goals of the test artifact is to reduce testing friction, and if we don't ship libsasl2 and its modules, users may need to manually install some system packages (the libsasl2 package is pretty common, but some of the modules less so). This choice and its inherent trade-offs are non-obvious and should be documented.

Issue Links

• relates to: KUDU-2411 Create a public test utility artifact