vote for systemd: Nay.

[Lennart Poettering]

On Tue, 02.07.13 10:08, Jean-Marc Pigeon (jmp at safe.ca) wrote:
> This little project gave satisfactory results with various distributions when
> I designed and tested it 2 years ago. First I checked it with a standard
>   EL6.4 template (400 Megs) under this new kernel (3.9.4,  HOST
> EL6.4) to see if my tool was
> still operational. Everything went perfectly. I was ready to test
> FC18. The selected
> FC18 template is a very standard one (a 939 MBytes tgz file) which
> (and this is a key factor) was proved to be fully working "as is" in an openvz
> container (kernel 2.6.32-042stab076.8). "as is" means that Template
> was never taylored
> to be on openvz container (template is used out of the box in openvz
> container) and could
> be used to seed a working HOST too.

So, as you mentioned earlier you used this recipe to set up your image:

https://gist.github.com/fabaff/5512671

This recipe is very broken (which I already told you), and by using
this, you create an OS image that changes a number of early boot things
in a way that will break things if you then try to boot the same image
on bare metal.

The things it changes are early-boot things, very low-level stuff. You
interfered with much of the most basic OS initialization stuff there
(masking sysinit.target!), and if you do this then you really need
to know what you are doing. And you should not expect that the same
image will then continue to boot on normal hardware.

I understand you are new to systemd, but you chose to alter the lowest
level bits of the OS, and then were subsequently lost then. This is
certainly very understandable, but please accept that this is not our
primary use case. We assume that if you touch that kind of low-level
stuff, and alter the early-boot dep tree, then you know how to help
yourself. The more low-level you go the more expertise you need.

We are working on making systemd work out-of-the-box on container
managers. libvirt-lxc and systemd-nspawn are relatively nicely
integrated with systemd so that things just work without any manual
recipe. OpenVZ is not something we test against, and we certainly do not
test systems that have been modified to work with OpenVZ but then are
attempted to be booted on bare-metal hardware again.

>From the systemd side it is our goal to ensure that systemd will work
fine on bare metal, inside a VM and in a container, with the exact same
image, without any ateration. With nspawn/libvirt-lxc we are very close
to that. However, all that work will be incomplete, unless Fedora as a
whole starts to care about this (for example, by giving the various
container managers a role like a "release architecture", to ensure they
just work with unmodified future fedora releases), and unless the
various container managers actually start to implement the most basic
common interfaces like the ones we documented:

http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/

So, please work with Fedora, with the container vendor of your choice to
make all this stuff just work out-of-the-box. And please don't use
recipes like the one you linked, they made things worse, not better. You
don't need any recipes at all if your container manager just implements
the ContainerInterface mini spec...

Being able to migrate OS images between VMs, bare metal, containers, in
all directions without alteration is absolutely a worthy goal, and not
far off, if people actually start caring.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.