I’m glad this discussion is happening on dev@ :) Personally I like customizing with shell env variables during rolling my own image, but definitely documentation the expectations/usage of the variables is needed before we can really call it an API.
On the related question I suspect two of the more “common” likely customizations is adding additional jars for bootstrapping fetching from a DFS & also similarity complicated Python dependencies (although given the Pythons support isn’t merged yet it’s hard to say what exactly this would look like). I could also see some vendors wanting to add some bootstrap/setup scripts to fetch keys or other things. What other ways do folks foresee customizing their Spark docker containers? On Wed, Mar 21, 2018 at 5:04 PM Erik Erlandson <eerla...@redhat.com> wrote: > During the review of the recent PR to remove use of the init_container > from kube pods as created by the Kubernetes back-end, the topic of > documenting the "API" for these container images also came up. What > information does the back-end provide to these containers? In what form? > What assumptions does the back-end make about the structure of these > containers? This information is important in a scenario where a user wants > to create custom images, particularly if these are not based on the > reference dockerfiles. > > A related topic is deciding what such an API should look like. For > example, early incarnations were based more purely on environment > variables, which could have advantages in terms of an API that is easy to > describe in a document. If we document the current API, should we annotate > it as Experimental? If not, does that effectively freeze the API? > > We are interested in community input about possible customization use > cases and opinions on possible API designs! > Cheers, > Erik > -- Twitter: https://twitter.com/holdenkarau
