On Thu, Dec 17, 2015 at 10:02:43AM -0500, Colin Walters wrote: > On Thu, Dec 17, 2015, at 08:28 AM, Neil Horman wrote: > > > > I would question why its necessecary to keep systemd out so ardently. If you > > build your container layers properly, you can effectively put systemd in a base > > container and layer other applications in child containers that inherit from it. > > If one is doing "micro" containers that only have typically one process in them, > having systemd managing it is unnecessary overhead. > Well, thats true, but if thats the use case you're focused on, one would imagine you either: 1) Writing your container install script to simply copy in only the files needed for the process that you want 2) Writing your container install script to minimize filesystem contents after then install In either case, you're going to wind up butchering a fair amount of what the rpm is going to be doing anyway. If its so important to minimize that storage, rpm dependencies shouldn't really be a big deal, because you know you're going to have to either do some FS surgery anyway. At that point all your saving is the time to download systemd. It seems like this is making alot of tradeoffs to do something that you'll need to do anyway. Neil > There are some outstanding issues with this model; need a way to tell > a pid namespace to auto-reap children in the kernel so pid 1 doesn't have to know > to do that. > Yeah, thats the argument behind doing a properly layered container. Spend the 300Mb to get systemd and its dependencies once, and make all your other contaienrs children of that. The children inherit the systemd code, they temselves are still minimized, and you can use systemd to do process management in the container. Yes, its more than one process. I think thats the better tradeoff though. Neil > But we should also obviously support systemd-in-container as a lot of > people are in a middle phase of "virt lite" with containers. > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
