On Thu, Dec 17, 2015 at 03:39:17PM -0500, Colin Walters wrote: > On Thu, Dec 17, 2015, at 01:19 PM, Neil Horman wrote: > > > > 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. > > What I'm actually arguing long term is to rearchitect the model of the subset > of Fedora that is for server containers to support this - something like a "just the binaries" > data blob, and then *optionally* turn that intermediate into an RPM that would > have a systemd unit file. It could really be an RPM, just without the %post > scripts relating to systemd and the unit files. > sooo, you're advocating for an intermediate RPM that is just what you need for your use case, to which you could then add additional metadata/tags/etc later? That...seems like alot of work for very little value. Lets try a example: httpd. If you want to run a webserver in a microcontainer, under this model, you would wind up packaging /usr/sbin/apachectl, /ur/sbin/fcgistarter, /usr/sbin/httpd, /usr/sbin/suexec, /usr/sbin/rotatelogs, dozens of module files, and a host of default page images. Presuming you want your web server to do a bit more, your docker file still needs to: 1) remove at least 3 of those binaries, as well as the default image files 2) remove any and all of the modules that you don't plan to use 3) add a config file 4) write a startup script so docker knows how to start this thing So, even if you have 'just the binaries' packaged, you still have to do a metric butload of file system surgery to arrive at your minimal microcontainer goal. So packaging all the binaries alone hasn't bought you anything. At the above point you've downloaded, installed and erased about 6Mb of data. At that point the other 24Mb for systemd really isn't much of a headache to deal with, especially if the cure is making a major overhaul to our packaging tool. Just out of curiosity, if you wish to avoid all these dependencies, why not just writ a simple plugin to dnf to not depsolve anything, so you only install specifically what you ask for? It might even be as simple as passing -x systemd to the operation, so dnf exludes systemd from the operation. > In practice though, it's not a big deal as long as shared libraries don't > end up pulling in systemd or other components. And for software that's > container-only, the build process (Dockerfile or something better in the > future) for containers just won't require it. > > > Yes, its more than one process. I think thats the better tradeoff though. > > What you're arguing is that *build* convenience for our current architecture > outweighs the *runtime* cost. That doesn't make sense long term - they're > different problems. What runtime cost are you referring to here? The cost of running systemd in a container? Its miniscule, given that its only job is to start a handful of units and get out of the way. If its so important to not use up that small additional amount of ram and cpu, so be it, but that seems like a different question than the one being addressed. Initially we were talking about minimzing container size, not runtime speed. If thats what you want, perhaps the solution is to provide tunables (if they don't already exist), to ensure that systemd optimizes its runtime for memory size and cpu usage, but its alreay not that big in those areas. Neil > -- > 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
