Server Technical Specification: Agenda and First Draft

[Jon]

The base wg has been wondering the same for containers, and at this point
we may follow this guidance regarding libvirt too. I'll probably advocate
this at our next meeting.

Thanks
On Mar 3, 2014 6:09 AM, "Stephen Gallagher" <sgallagh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/28/2014 07:19 PM, Lennart Poettering wrote:
> > On Fri, 28.02.14 15:37, Daniel J Walsh (dwalsh at redhat.com) wrote:
> >
> >>> <drago01> sgallagh: "systemd-nspawn will be used to manage
> >>> containerization capabilities. " did I miss something or
> >>> doesn't upstream say that it should not be used for anything
> >>> that needs secruity? <sgallagh> drago01: Last I heard, the Dans
> >>> (Walsh and Berrange) had SELinux working with it now. <mclasen>
> >>> dargo01: I think that statement may be evolving ? <sgallagh>
> >>> And Docker is moving to systemd-nspawn and away from lxc
> >>> <mclasen> but certainly valuable to raise the question on the
> >>> list, and see if lennart, dan or dan want to chime in <drago01>
> >>> sgallagh: "Note that even though these security precautions are
> >>> taken systemd-nspawn is not suitable for secure container
> >>> setups. Many of the security features may be circumvented and
> >>> are hence primarily useful to avoid accidental changes to the
> >>> host system from the container. The intended use of this
> >>> program is debugging and testing as well as building of
> >>> packages, distributions and software involved with boot and
> >>> systems mana <drago01> gement." [1] <sgallagh> So it's
> >>> definitely the way forward. <drago01> sgallagh, mclasen : ok
> >>> makes sense
> >>>
> >>> So I am not sure if that has changed yet or not but if it has
> >>> we should at least get the man page updated.
> >>>
> >>> 1:
> >>> http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
> >>> (man page)
> >>>
> >> Well this has changed again.   Docker is now going native.  It
> >> will support containers directly and not require a different set
> >> of tooling like lxc, systemd-nspawn or libvirt-lxc.
> >>
> >> This will be the default, and I guess people could experiment
> >> with others.
> >
> > Originally, nspawn was mostly just a debugging tool for us, since
> > that way we could boot up a systemd instance in an environment that
> > is pretty much like a real system but allows us to attach gdb
> > easily. We never intended it really to be more than that. That
> > said, it considerably grew in features over time (espcially, after
> > Dan asked us to add a couple of features for them), and it is quite
> > a powerful tool now.
> >
> > At this time I am aware of some people using it in production,
> > simply because it is much easier to use as you don't need to set up
> > any configuration for it. However, I personally am very much of the
> > opinion that libvirtd is the right choice if you want to deploy
> > something. It has all those management features, APIs, and tries to
> > be general purpose, and nspawn doesn't have or try anything of
> > that. Hence it should be libvirt-lxc that Fedora should advertise
> > for deployment on its server edition. People are of course welcome
> > to use nspawn, but it appears wrong to me to advertise it for
> > servers, nspawn is not specifically designed to be deployed or to
> > be server tool.
> >
> > The container hook-up work we are doing within the systemd project
> > is always designed to be compatible with any container manager
> > people choose as long as it follows these guidelines:
> >
> > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
> >
> >
> http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/
> >
> > Both libvirt-lxc and nspawn implement these interfaces, you will
> > get the same level of integration with them.
> >
> > Docker is will use its own containerization code soonishly. I am
> > pretty sure that that's actually the right choice for them. They
> > are following the container guidelines too, to provide the same
> > level of integration.
> >
> > (And regarding the comments on security from the man page: yes,
> > with nspawn we do not make any claims about being secure, but
> > that's mostly inherent to the underlying technologies and hence
> > mostly applies to the other container managers in the same way
> > too).
> >
> > So, from my PoV that wiki text should really just say "libvirtd",
> > and nothing else. For both VM and container virtualization.
> >
>
> Thank you very much for this detailed response, Lennart. It's much
> appreciated.
>
> With this in mind, I'm going to revise the document to recommend
> libvirt as the preferred container management tool.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlMUcSAACgkQeiVVYja6o6MdygCfYhBWlOQkLXqNJ1PEPE4kncFl
> gUEAniBac8H2rMi3vZxodq4kib8LlNtD
> =T5Mz
> -----END PGP SIGNATURE-----
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140303/a095d25a/attachment.html>