Closed rbalint closed 2 years ago
This results in Ubuntu lxd containers to come up degraded by default, which is not nice. And I do agree that dumpconf doesn't make sense to run inside containers.
I think one can even specify it as:
ConditionVirtualization=!container
As this service only makes sense on LPAR, z/VM, kvm hosts and not inside container guests.
To only start this service on LPARs and z/VMs, but not in any other
To avoid attempting to start dumpconf under
And what about a privileged container ? It could probably make sense to run dumpconf inside a privileged container that would be able to setup dump parameters.
And what about a privileged container ? It could probably make sense to run dumpconf inside a privileged container that would be able to setup dump parameters.
Privileged containers are quite rare and most likely this service should run on the host IMO. This change can be overridden in local configuration if this is really needed.
And what about a privileged container ? It could probably make sense to run dumpconf inside a privileged container that would be able to setup dump parameters.
in normal / regular setups that does not make sense.
It only makes sense on systems that have no host at all, where all the "host" config is done from a container too..... then such a system-control container will do lots of interesting things like rebooting the host. KubesOs / CoreOS come to mind, which would then need to adjust this. If they rely on this. But that's very niche and specific to those deployments. The vast majority of stock linux distors (ubuntu/rhel/suse) would not want dumpconf to run from a container by default (priviledged, or not).
I'm not familiar with LXC but how come a system service is executed inside a container ? With Docker, it is commonplace to run a single application inside a container and running system services like systemd is considered a bad practice. How come a system service like dumpconf is being executed inside a container ?
I'm not familiar with LXC but how come a system service is executed inside a container ? With Docker, it is commonplace to run a single application inside a container and running system services like systemd is considered a bad practice. How come a system service like dumpconf is being executed inside a container ?
docker is usually a single process container. However, one can also run systemd as the "single process" and start a fully functional system, all the way to multi-user.target.
lxc is a system container. I.e. you may know these type of container management solutions as systemd-nspawn, virtuozzo, openvz, VPS. By default it does launch /sbin/init and start all the services and boots to multi-user.target. One cannot usually modprobe new kernels or affect /dev /sys of the host, but one does have ssh.service / apache2.service and all the usual things running like on a normal system. Meaning all the services are running.
lxd is available on s390x, one can install as a snap from the snapstore and launch images as one likes.
See https://linuxcontainers.org/lxd/getting-started-cli/
There are ubuntu images published for s390x as ubuntu:focal for example, but there are also s390x images published at the images: endpoint for fedora debian alpine all for s390x, and multiple releases.
I often use lxd to quickly spin up a "fedora" container to compare how things are done for s390x there vs Ubuntu, to reproduce / compare bugs, test toolchains, etc.
This is an attempt to revitalize this 'cold case', so I'm trying to re-cap:
I guess we can probably agree that:
In case yes, a good default is obviously one that is good for the majority of cases, hence best practice is surely to have: ConditionVirtualization=!lxc in as default.
I think it just doesn't make sense having a default value that addresses just exceptional cases.
If such a rare case, where it really need to be changed occurs, it'll be a special case, that is then highly likely treated by an advanced user who probably knows what he/she is doing (and not vice versa).
Just m 2-cents.
This got lost again, I'll take the PR and even change it to !container
as suggested.
That would be great - thx!
It just fails to start in unprivileged containers
Signed-off-by: Balint Reczey balint.reczey@canonical.com