> On Oct. 1, 2015, 4:31 a.m., Jojy Varghese wrote: > > src/docker/docker.cpp, line 681 > > <https://reviews.apache.org/r/38910/diff/1/?file=1088143#file1088143line681> > > > > wondering this behavior should be defaulted or not. We might be > > overloading stop with more than what it should be doing isnt it? Do we > > always want to force remove the volumes when docker stops?
My & Tim's original thought was that because persistent volumes aren't explicitly implemented for the Docker containerizer currently, we could safely make `-v` the default behavior. However, after considering a bit more, I'm thinking that existing user workflows might establish a Docker volume on an agent with the intention of returning to it later with a subsequent task, in which case defaulting to `-v` would break this workflow, so making this an optional argument may be a good idea. I'll have to think about what is the best way to pass this option to the agent, any thoughts on that matter would be appreciated! - Greg ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38910/#review101192 ----------------------------------------------------------- On Sept. 30, 2015, 11:51 p.m., Greg Mann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38910/ > ----------------------------------------------------------- > > (Updated Sept. 30, 2015, 11:51 p.m.) > > > Review request for mesos, Gilbert Song, Jojy Varghese, and Timothy Chen. > > > Bugs: MESOS-2613 > https://issues.apache.org/jira/browse/MESOS-2613 > > > Repository: mesos > > > Description > ------- > > Added `-v` flag to `docker rm`. > > > Diffs > ----- > > src/docker/docker.cpp afcedf1f1a309bd0626c33ee25694ac1b43bdec7 > > Diff: https://reviews.apache.org/r/38910/diff/ > > > Testing > ------- > > `make check` > > DockerContainerizerTest.ROOT_DOCKER_Launch_Executor fails on my Ubuntu 14.04 > VM, but this is a known issue: MESOS-3123 > > > Thanks, > > Greg Mann > >
