Versioning/release management would seem to be a valid concern though. Do you have a tagging/versioning scheme in mind? Would the image get "released" on the same cycle as Yetus itself or managed independently?
If the intent is for our users to specify this as their base image in the FROM clause, then I'd want them to be able to pin to a specific, immutable version. If the intent is only to provide a starting sample and not a base image, then I think versioning is less of a concern. --Chris Nauroth On 11/9/15, 11:34 AM, "Andrew Bayer" <[email protected]> wrote: >Ok - I was just making sure we weren't putting Yetus code in it, since >that >runs into the questionable area of "releasing" unreleased code, which Sean >has a history of hunting down and throwing things at. =) > >Given that it's clear in that regard - yeah, sounds like a really good >idea. > >A. > >On Mon, Nov 9, 2015 at 11:21 AM, Allen Wittenauer <[email protected]> >wrote: > >> >> > On Nov 9, 2015, at 11:14 AM, Andrew Bayer <[email protected]> >> wrote: >> > >> > What's on the default Docker image? >> >> >> Quite a bit, actually. It¹s mostly dependencies for all the >> plug-ins we support plus all the components Hadoop needed to build as >>of a >> few months ago. I¹m going to move Hadoop to its own Yetus-compatible >> Dockerfile (HADOOP-12562) so the Hadoop dependencies can come out. But >>it >> would be extremely useful to be able to do (yetus image) + (hadoop >>extras) >> = (container). >> >> >> >>https://github.com/apache/yetus/blob/e26177a03d7629e28464dc3a1687e6ef73bf >>b7fa/precommit/test-patch-docker/Dockerfile-startstub
