4 ms·

@cwyers I understand this problem. However, this wasn't an acceptable situation for Docker to be in, because there is seemingly no choice "B" in which Docker co

@cwyers I understand this problem. However, this wasn't an acceptable situation for Docker to be in, because there is seemingly no choice "B" in which Docker comunicates with cgroups in a non-init system specific maner. I accept the concept that this is a hard technical problem, preventing race conditions while allowing more than one program to run on your system (to put it flatly), but tying Docker to systemd just wasn't an acceptable option. I think that RedHat IS at fault in this, because their design choice of designating systemd as the single writer was extremely anti-standardization. Imagine if KDE wanted to be the single cgroup writter. Would people accept the fact that they would have to use KDE and interface with KDE in order to do containers on Linux? RedHat could have created a service "cgroupwriter" which would have communicated via D-bus or something. A "cgroupwriter" service would be far less divisive because it wouldn't be divisive on other issues such as choice of init system.

jkyle 11y ago
> I think that RedHat IS at fault in this, because their design choice of designating systemd as the single writer was extremely anti-standardization. Imagine if KDE wanted to be the single cgroup writter. This isn't a very good analogy. > I think that RedHat IS at fault in this, because their design choice of designating systemd as the single writer was extremely anti-standardization. This doesn't make sense. When the changes hits the kernel, all OS maintainers will need to choose a parent process for all cgroup control. Supporting this feature in systemd makes perfect sense and fits very well in the process hierarchy. > Would people accept the fact that they would have to use KDE and interface with KDE in order to do containers on Linux? 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. In short, you are not required to use systemd if they make this choice. You may not have the benefit of someone else implementing the solution for you. But unless you're paying developers for the work, the guarantee of others doing work for you in the way you want them to is never provided. > RedHat could have created a service "cgroupwriter" which would have communicated via D-bus or something. They could have, but it would have added needless complexity. A significant number of tasks systemd needs to perform includes dependencies between cgroups. So mine as well manage it in the init system. This isn't like a hard dependency on systemd. It just means that someone will need to author other solutions if systemd is not wanted.
- cwyers 11y ago
  Or put another way. The kernel is deprecating multi-writer support for cgroups at some point in the future. systemd has announced they will provide an API for cgroups, where systemd serves as the single writer. On systems not using systemd, some other service will have to serve as the single writer for cgroups. They may or may not implement the same API. (I don't know that anyone has announced plans for an alternative to systemd's cgroups API.) Once this changeover happens, systemd's API will be the only way to use cgroups on systemd systems. This isn't portable, but that's not a problem with Red Hat's contributions to Docker, it's an issue with systemd. Kicking RHEL's contributors to Docker out doesn't actually solve this problem.
  - jkyle 11y ago
    > it's an issue with systemd I wouldn't even say this is an issue with systemd. It just happens that systemd (or logind actually) is what was selected as the cgroup controller on distributions that use it. Mostly, it's an issue with Docker (and all other cgroup clients) that are currently using their own controllers. It doesn't matter one bit what the distributions chose as their new controller, the existing clients would need to adapt to the new environment. If anything, having systemd handle this has simplified their jobs significantly since they can support a huge swath of distributions capturing the overwhelming majority of user's systems by targeting a single API.
- timthelion 11y ago
  > 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.
ambrice 11y ago
The linux kernel is breaking the way Docker currently uses cgroups. And systemd is providing a fix for systems running systemd, but this is their fault because systemd is not also providing a fix for systems that aren't running systemd?

jkyle 11y ago

> I think that RedHat IS at fault in this, because their design choice of designating systemd as the single writer was extremely anti-standardization. Imagine if KDE wanted to be the single cgroup writter. This isn't a very good analogy. > I think that RedHat IS at fault in this, because their design choice of designating systemd as the single writer was extremely anti-standardization. This doesn't make sense. When the changes hits the kernel, all OS maintainers will need to choose a parent process for all cgroup control. Supporting this feature in systemd makes perfect sense and fits very well in the process hierarchy. > Would people accept the fact that they would have to use KDE and interface with KDE in order to do containers on Linux? 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. In short, you are not required to use systemd if they make this choice. You may not have the benefit of someone else implementing the solution for you. But unless you're paying developers for the work, the guarantee of others doing work for you in the way you want them to is never provided. > RedHat could have created a service "cgroupwriter" which would have communicated via D-bus or something. They could have, but it would have added needless complexity. A significant number of tasks systemd needs to perform includes dependencies between cgroups. So mine as well manage it in the init system. This isn't like a hard dependency on systemd. It just means that someone will need to author other solutions if systemd is not wanted.

cwyers 11y ago
Or put another way. The kernel is deprecating multi-writer support for cgroups at some point in the future. systemd has announced they will provide an API for cgroups, where systemd serves as the single writer. On systems not using systemd, some other service will have to serve as the single writer for cgroups. They may or may not implement the same API. (I don't know that anyone has announced plans for an alternative to systemd's cgroups API.) Once this changeover happens, systemd's API will be the only way to use cgroups on systemd systems. This isn't portable, but that's not a problem with Red Hat's contributions to Docker, it's an issue with systemd. Kicking RHEL's contributors to Docker out doesn't actually solve this problem.
- jkyle 11y ago
  > it's an issue with systemd I wouldn't even say this is an issue with systemd. It just happens that systemd (or logind actually) is what was selected as the cgroup controller on distributions that use it. Mostly, it's an issue with Docker (and all other cgroup clients) that are currently using their own controllers. It doesn't matter one bit what the distributions chose as their new controller, the existing clients would need to adapt to the new environment. If anything, having systemd handle this has simplified their jobs significantly since they can support a huge swath of distributions capturing the overwhelming majority of user's systems by targeting a single API.
timthelion 11y ago
> 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.

ambrice 11y ago

The linux kernel is breaking the way Docker currently uses cgroups. And systemd is providing a fix for systems running systemd, but this is their fault because systemd is not also providing a fix for systems that aren't running systemd?