On Mon, Oct 20, 2014 at 3:24 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Mon, 20.10.14 15:08, Matthew Miller (mattdm@xxxxxxxxxxxxxxxxx) wrote: > >> On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote: >> > But again, I am not sure I understand what is going on here. Is >> > systemd now optional in Fedora? >> >> I guess to some degree everything is "optional" in one way or another. >> It's certainly the init system we are using. I think the context is in >> cases where the packages are used without an init system, systemd or >> otherwise — the main case being single-process (or at least >> single-parent-process) application containers. >> >> (I'm also looking forward to systemd as a process manager inside e.g. >> Docker for more sophisticated multi-process applications which for >> whatever reason want to be in the same container, but that's a >> different use case.) > > While I can see the reason why you want this I really find this quite > dubious in general. Much of our stack relies on /run and all those > other facilities, of our general execution environment to be properly > initialized, cleaned up and maintained. We do this with tmpfiles > snippets, early-boot services, cron jobs, timer units, and so on and > so on. > > Just saying "no" to these things, ignoring them and not executing them > will only get you so far. It also creates in a way a new execution > environment, unless you perfectly replicate the execution > environment from your container manager, knowing all components in > play, including all libraries and whatever else. A container is _absolutely_ a "new execution environment", and the whole advantage of it, to most users, is that it's more lightweight than a complete virtualized OS environment, partly because you do not have to load an entire operating system. There is enough abstraction to make running a distinct set of packages (even a different distro/version) reasonable, but with the luxury of not having to deal with network setup, filesystem checks and mounts, initialization of cgroups, and all those other fun things, because a combination of systemd, docker, and other host services have done all the work. And things like logging the output of the service, restarting it if it crashes, etc. can easily be taken care of by making a systemd unit for the container in the *host* OS. I'm not sure what to make of your comment about "knowing all component in play, including all libraries and whatever else," because that seems to indicate that you are worried about dependency closure inside the container, which is the responsibility of whomever built the container. Assuming they did so in a sane way with a package management system, they will be fine from that standpoint. > If you really intend to make Fedora in general workable without > providing support for tmpfiles bits, without cron jobs, without timer > units, without setting up the execution environmnt the same way as on > a classic Fedora boot, then please make this a clear goal of > Fedora. But just trying to add this through the backdoor sounds wrong. First, I would say that the community has rammed this requirement right through the front door. People _are_ running things this way. This is not some theoretical future feature; it's an adaptation to existing use cases. Second, things like tmpfile cleanup and log rotation are not requirements for a service to function. This is why, for example, none of the many packages which put file in /etc/logrotate.d/ actually require logrotate. Sure, it's nice if it's there, but a user is also free to come up with their own procedure for rotating logs, or to not rotate them at all. I would be interested to know some other concrete examples of concerns about the "execution environment" that would actually impact the functionality of a service in a container. I won't claim that such things don't exist, but tmpfile clean-up and log rotation are poor examples, IMHO. > Honestly though, I really don't think this is really such a good > idea. You make things much more complicated for developers that > way. We *want* developers to make use of the OS services we provide > after all. It makes the system more uniform and more accessible to our > admins and users. If you take the vast majority of the facilities that > we provide for software away, then very little remains, you devalue > the OS itself. We are not taking these things away. Matt even mentioned that he would like to see us provide containers with systemd inside them as an option, but it will necessarily be a more heavyweight option than the current use case which has become so common, and it will be uninteresting to many users. The value in these OS services of which you speak are significant in the host OS, which has to manage the orchestration of many containers in this new world. For the developer (who is *not* a sysadmin) the value of these services is quite minimal. They want to build an app, and run the app, and to have as little concern as possible for the environment in which it runs. I can hardly imagine a more uncomplicated world than what they are already creating for themselves. Andy > > Lennart > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
