Yup . By forcing users to interact with docker, you are inviting all sorts of hacks and trouble. Same if you have them use vbox/libvirt directly.
U know... There is this Tool... it starts with a "v", it insulates users from this crap ... :) > On Sep 3, 2014, at 2:43 PM, Konstantin Boudnik <[email protected]> wrote: > > 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
