Background
Currently ctr install is limited to installing plugin images which are either statically compiled or contain lib dependencies. This is complicated when a plugin binary is not statically compiled because one of the lib dependencies is either libc or libmusl. Additionally there are library dependencies related to selinux, apparmor, and devmapper which may make distributing the right binary complicated. If the manifest list could ship multiple manifests for each platform with different os.features, it would be a better experience for the client.
Proposal
Define a format for specifying specific library dependencies in os.Features. Since these features are a string array, there could be multiple and follow a key=value format. These features would be set by both the image builder and pull client. The pull client could safely ignore features it does not know about and existing clients would not be affected.
Feature format
Each feature will have a key and a value. A key would represent a system property, library, or class of library. The value could be a specific value or yes/no.
grammar
feature := name '=' value
name := [a-zA-Z0-9]+
value := [a-zA-Z0-9][a-zA-Z0-9-._]*
Note this just attempts to cover features defined here, any additional features including which don't match the grammar may be safely ignored. Namespacing should be unnecessary here since the meaning should be unambiguous and not specific to any implementation.
Features
| Name |
Values |
Description |
| libc |
glibc or musl |
The c library dynamic binaries are linked against |
| lsm |
apparmor or selinux |
The Linux Security Module required by the binaries |
| libudev |
yes or no |
Whether libudev is required by the binaries, no if not included |
Implementation
Provide a buildkit frontend which is capable of defining these os.feature sets and building multi-arch manifests containing each set of features.
Update ctr install to probe the local libraries and set os.features in the platform it uses for fetching and resolving images.
Update platform matcher to check and sort by os.features. Note the logic should be if a feature name is both given by the client and in the image, the feature value must match. If the feature is not included by either, then it cannot be used for matching, but may be used for sorting (such as sort more generic items with less unknown features higher).
Background
Currently
ctr installis limited to installing plugin images which are either statically compiled or containlibdependencies. This is complicated when a plugin binary is not statically compiled because one of the lib dependencies is eitherlibcorlibmusl. Additionally there are library dependencies related toselinux,apparmor, anddevmapperwhich may make distributing the right binary complicated. If the manifest list could ship multiple manifests for each platform with different os.features, it would be a better experience for the client.Proposal
Define a format for specifying specific library dependencies in
os.Features. Since these features are a string array, there could be multiple and follow akey=valueformat. These features would be set by both the image builder and pull client. The pull client could safely ignore features it does not know about and existing clients would not be affected.Feature format
Each feature will have a key and a value. A key would represent a system property, library, or class of library. The value could be a specific value or
yes/no.grammar
Note this just attempts to cover features defined here, any additional features including which don't match the grammar may be safely ignored. Namespacing should be unnecessary here since the meaning should be unambiguous and not specific to any implementation.
Features
glibcormuslapparmororselinuxyesornonoif not includedImplementation
Provide a buildkit frontend which is capable of defining these os.feature sets and building multi-arch manifests containing each set of features.
Update
ctr installto probe the local libraries and setos.featuresin the platform it uses for fetching and resolving images.Update platform matcher to check and sort by
os.features. Note the logic should be if a feature name is both given by the client and in the image, the feature value must match. If the feature is not included by either, then it cannot be used for matching, but may be used for sorting (such as sort more generic items with less unknown features higher).