On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson ([email protected]) wrote:
> >>I thought fancy enterprise features like this was on hold until networkd was > >>"ready" ? > >This is not an enterprise feature. It's a promise one cannot keep. We > >will not add code to systemd that works often but not always, and CRIU > >is certainly of that kind. > > "We will not add code to systemd that works often but not always" you need > to explain this a bit further since we might have different perception on > this since from my perception such code has been added to systemd in more > then one occasion anyway I was not advocating for the use/inclusion of CRIU > but something built in. > > We should be able to support non live migration out of the box if live > migration is a pandora's box or are you opposed to that as well? Well, sure, it would be nice, but I also believe it is not realistic to support. For example, if you have network protocols you can probably still live with their connections being severed during migration, but this is really not the case for local IPC connections, like bus connections. Restoring the state for that is an immense amount of work, and I am pretty sure that it is not desirable to add code for this to all IPC systems like this just because of CRIU. Also, I doubt this really is such an important thing to have. I mean, containers are not VMs, they are easily instantiated and shut down. You can socket actviate them, and have them exit-on-idle. If you accept that containers are a much more volatile, dynamic thing that VMs then live migration becomes much less attractive. I am pretty sure you can make CRIU work for a lot of cases. But it's obvious that it will fail to save/restore a large number of cases, including any that involve dbus or any other non-trivial IPC (X11, PA, mysql connections, ...), hence it's really a promise you cannot keep, and I will not support something with systemd that is pretty obviously unsupportable. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
