The order does matter. Let me try and elaborate. Each containerizer in the list is tried, one at a time, to launch the container. If a containerizer does not support launching the kind of container requested (i.e., a Docker container), then the next containerizer is tried. So, if you did:
--containerizers=external,docker,mesos And whatever external containerizer you're running supports launching Docker containers then the DockerContainerizer will never be used (in fact, if your external containerizer supports creating all kinds of containers then none of the other containerizers will ever be used). After 0.20.1 (or if you're running from trunk), the order shouldn't matter if you're just using the 'mesos' and 'docker' containerizer: --containerizers=mesos,docker --containerizers=docker,mesos *But the order will still matter if you also want to use the external containerizer!* Hope that helps. Ben. On Wed, Aug 27, 2014 at 10:37 AM, Tim Chen <[email protected]> wrote: > Hi Frank, > > Yes, the order shouldn't matter. Sorry for the confusion. > > Tim > > > On Wed, Aug 27, 2014 at 10:24 AM, Frank Hinek <[email protected]> > wrote: > >> So if I’m reading this correctly the order shouldn’t matter if you are >> running from trunk or the future 0.20.1 release? >> >> >> On August 27, 2014 at 1:21:02 PM, Tim Chen ([email protected]) wrote: >> >> Hi Vinod, >> >> Yes we realized that as well, the order affect the evaluation of the >> containerizers but I see Mesos Containterizer will not launch if >> ContainerInfo is set. >> >> Tim >> >> >> On Wed, Aug 27, 2014 at 10:15 AM, Vinod Kone <[email protected]> wrote: >> >>> >>> On Wed, Aug 27, 2014 at 9:14 AM, Connor Doyle <[email protected]> >>> wrote: >>> >>>> The order they are listed is significant >>> >>> >>> Why is the order important? Is it a Marathon restriction? IIUC, Mesos >>> will pick the right* containerizer based on whether TaskInfo.ContainerInfo >>> or ExecutorInfo.ContainerInfo is set. >>> >>> * there is currently a bug that depends on the order but that is already >>> fixed on trunk and will be included in 0.20.1 release. >>> >> >> >
