My only comment would be to have bigtop-deploy/docker instead of proliferation of the top-level directories. After all, dockers is just yet another technology that might or mightn't be used for certain things like cluster deployment.
Other than that I let ppl w/ more experience in this tech. to chime in. Cos P.S. As a side rant, more I am looking into Dockers less I like it, to be honest. It feels like goddamn 1983 with the stupid port-forwarding hacks and non-isolated kernels. Honestly, it is pretty awful to be considered a serious competition to KVM. And please, please - don't bring Google example into this conversation: the amount of the dockers' relevant patches they haven't contributed back to the Linux community is staggering. So, for all I'm concerned - Google is using a technology very different to that of OSS dockers, hence their case isn't applicable to our settings. On Tue, Sep 02, 2014 at 08:55PM, jay vyas wrote: > Hi bigtop/. > > I got some time to work on bigtop-1235, finally. > > I'd like to add a docker based "test" of it as part of the patch. > > Im wondering if we;'ve decided on a way we are planning on > organizing the work around docker. > > Options: > > 1) possibly we could add a new directory, each with a docker > recipe and README for a given task , like this: > > bigtop-docker/ > build-all-rpm/ > Dockerfile > README > build-all-deb/ > run-smoke-tests/ > Dockerfile > README > test-puppet-hcfs/ > Dockerfile > README > > This way, the dockerized tasks are centralized into a part of the codebase, > rather > than being strewn about in various places. > > 2) Another way we can do it , is we can agree that certain directories will > contain a Dockerfile+README instructions about how to use that Dockerfile. > And each directory > manages this on its own. > > Other thoughts on where the docker functionality should go, and how we will > maintain it? > > > -- > jay vyas
