17 ms·

> Users and distributions who do not want to use systemd (their choice!) can use any other init system they want. They are also free to implement any other solu

> Users and distributions who do not want to use systemd (their choice!) can use any other init system they want. They are also free to implement any other solution as their cgroup controller. Their situation is not changed one iota by this additional feature in systemd. They would have had to implement a cgroup controller either way. The trouble is, that Docker doesn't get to choose what cgroup controller "everyone" will use, it has to support them all. And the idea of interfacing with systemd on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-systemd version of cgroups control came out. While I agree with @cwyers that kicking the RedHat folks out doesn't help, it certainly felt to me like that particular discussion could have been phrased differently so that no conflict was created. For example, if the RedHat folks have said that there is going to be a single writer policy and systemd is a cgroup writer on systemd systems, that would have been far less combative than saying "and systemd is that writer". I know that the distinction is subtle, I'm not sure if I should try to find the origional thread. It was written as comments on diffs in a pull request. It would be therefore rather hard to find, and also I feel a little bad about pulling out exact names of the people involved because I think that the actual people working for RedHat are fine people who I don't want to attack and that this is somehow a problem of RedHat corporate policy and not bad apples.

jkyle 11y ago
I'm still not seeing the logic in your rationale. > The trouble is, that Docker doesn't get to choose what cgroup controller "everyone" will use, it has to support them all. Yes, this is an unfortunate consequence of the new kernel changes. Docker will need to interact with a controller. That controller might be different on different systems. Ergo, if Docker wants to support those systems it needs to support multiple controllers. > And the idea of interfacing with systemd on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-systemd version of cgroups control came out. Yes. But this would be the case no matter what controller was chosen for a particular distribution. For example, if Red Hat decided to implement a controller called Skunk one could say > And the idea of interfacing with skunk on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-skunk version of cgroups control came out. Same situation. No matter how you slice it, Docker now needs to support compatibility code for interacting with cgroups on systems it wants to support. > I know that the distinction is subtle It seems pretty meaningless. It's beginning to feel like the opposition, as described here, had little to do with anything technical or even design oriented and is more religious in nature. Would the same opposition have been made against my hypothetical skunk controller? If not, seems more like an editor war than a design or engineering disagreement.
cwyers 11y ago
> And the idea of interfacing with systemd on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-systemd version of cgroups control came out. Unless Docker is planning to move to running on BSD jails or fork the kernel, they have to do this no matter how unappetizing they find it, once the kernel moves to single writers on cgroups.
- mkw39ekdm 11y ago
  FreeBSD is working on Docker support: https://wiki.freebsd.org/Docker https://wiki.freebsd.org/Docker
  - fatherlinnux 11y ago
    Have fun with that. The Linux User Space will not work on a BSD kernel, so you would be forced into a BSD user space. Now you are back at Square Zero. There is nothing wrong with the BSD, but it's just another different thing to learn and work with. I am skeptical this is the right way of looking at the problem. Bottom line, the Linux Kernel changed, so Docker has to deal with it.
    - ibotty 11y ago
      > The Linux User Space will not work on a BSD kernel That's wrong, more or less. Read about Linux emulation on BSDs. Of course some low-level utilities won't work, but most of userspace does.

jkyle 11y ago

I'm still not seeing the logic in your rationale. > The trouble is, that Docker doesn't get to choose what cgroup controller "everyone" will use, it has to support them all. Yes, this is an unfortunate consequence of the new kernel changes. Docker will need to interact with a controller. That controller might be different on different systems. Ergo, if Docker wants to support those systems it needs to support multiple controllers. > And the idea of interfacing with systemd on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-systemd version of cgroups control came out. Yes. But this would be the case no matter what controller was chosen for a particular distribution. For example, if Red Hat decided to implement a controller called Skunk one could say > And the idea of interfacing with skunk on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-skunk version of cgroups control came out. Same situation. No matter how you slice it, Docker now needs to support compatibility code for interacting with cgroups on systems it wants to support. > I know that the distinction is subtle It seems pretty meaningless. It's beginning to feel like the opposition, as described here, had little to do with anything technical or even design oriented and is more religious in nature. Would the same opposition have been made against my hypothetical skunk controller? If not, seems more like an editor war than a design or engineering disagreement.

cwyers 11y ago

> And the idea of interfacing with systemd on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-systemd version of cgroups control came out. Unless Docker is planning to move to running on BSD jails or fork the kernel, they have to do this no matter how unappetizing they find it, once the kernel moves to single writers on cgroups.

mkw39ekdm 11y ago
FreeBSD is working on Docker support: https://wiki.freebsd.org/Docker https://wiki.freebsd.org/Docker
- fatherlinnux 11y ago
  Have fun with that. The Linux User Space will not work on a BSD kernel, so you would be forced into a BSD user space. Now you are back at Square Zero. There is nothing wrong with the BSD, but it's just another different thing to learn and work with. I am skeptical this is the right way of looking at the problem. Bottom line, the Linux Kernel changed, so Docker has to deal with it.
  - ibotty 11y ago
    > The Linux User Space will not work on a BSD kernel That's wrong, more or less. Read about Linux emulation on BSDs. Of course some low-level utilities won't work, but most of userspace does.