Description of problem: It would be really nice ( and probably a ( api ) requirement of the future ) to be able to create/install and bulk update machine systemd containers. I dont think this is that complicated to implement since basically the only thing dnf needs to know is the -installroot=[path] of the machine container as in to create a systemd container you basically do this... Create the install root directory # mkdir -p /containers/container01.example.com Install into the machine container # dnf --nogpgcheck --installroot=/containers/container01.example.com install # systemd passwd dnf fedora-release vim-minimal procps-ng Set root passwd # chroot /containers/container01.example.com/ su - root -c ". ~/.bash_profile; passwd" Start the container # systemd-nspawn -jbD -M/containers/container01.example.com container01.example.com And you are done. Now it would fantastic to be simply able to run dnf install -m <container> foo m == machine dnf performing step one and two dnf install -c -m <container> c == create dn update -m <container> Updates the container dnf update -m -a a == all machine container Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This change goes deeper than you think. If you are following the fedora-devel list, you could have seen this task on our team roadmap (C2-4), however we are talking about a mid-term future, something between 2 and 5 years. Thanks for the report anyway, we'll keep it for tracking purposes.
(In reply to Jan Zeleny from comment #1) > This change goes deeper than you think. If you are following the > fedora-devel list, you could have seen this task on our team roadmap (C2-4), > however we are talking about a mid-term future, something between 2 and 5 > years. Thanks for the report anyway, we'll keep it for tracking purposes. I actually follow that list to certain extent. Do you have a link to the thread that shows that roadmap and or a subject line I can search for. I've actually been pondering if it should be better to introduce a new command in systemd similar to solaris zoneadmin but Lennart frownes upon that and somehow expect user to use the virt stuff failing to understand ( or accept the fact ), that it will only cause confusion amongst administrators.
(In reply to Jóhann B. Guðmundsson from comment #2) > (In reply to Jan Zeleny from comment #1) > > This change goes deeper than you think. If you are following the > > fedora-devel list, you could have seen this task on our team roadmap (C2-4), > > however we are talking about a mid-term future, something between 2 and 5 > > years. Thanks for the report anyway, we'll keep it for tracking purposes. > > I actually follow that list to certain extent. > > Do you have a link to the thread that shows that roadmap and or a subject > line I can search for. Sure, it's "Software management: Call for RFEs results!" > I've actually been pondering if it should be better to introduce a new > command in systemd similar to solaris zoneadmin but Lennart frownes upon > that and somehow expect user to use the virt stuff failing to understand ( > or accept the fact ), that it will only cause confusion amongst > administrators. Well, the problem is not exactly in the area of Software Management either but we still want to embrace it and come up with some ideas how to make the work with containerized installations better. Of course there will be some limitations because the variety of container technologies is vast (systemd, libvirt-lxc, docker.io, ...) and some configurations cannot be grasped at all. Still, we need to start somewhere ...
What Jan said, low prio for now. Let's first wait until the smoke around different containers technologies clears. We will definitely support the users' winner but most probably won't support all of them.
(In reply to Ales Kozumplik from comment #4) > What Jan said, low prio for now. > > Let's first wait until the smoke around different containers technologies > clears. We will definitely support the users' winner but most probably won't > support all of them. Betting on systemd is sure start these days ;)
(In reply to Jóhann B. Guðmundsson from comment #5) > Betting on systemd is sure start these days ;) Johann, please enlighten us. How do the systemd containers compare to docker or lxc?
(In reply to Ales Kozumplik from comment #6) > (In reply to Jóhann B. Guðmundsson from comment #5) > > Betting on systemd is sure start these days ;) > > Johann, please enlighten us. How do the systemd containers compare to docker > or lxc? It's Ted and the systemd crew that are changing the cgroup landscape so one sure bet and a good starting point is to integrate it with systemd since it will be the best integrated one. ( Or to be phraze it differently other container solution will break while playing catchup to the changes being made to cgroups ) I suggest catching up to all the talk and flames about systemd being in charge of the cgroup hierarchy as a whole :)
I'm not sure this is the entire picture. Containerized applications are about more things than just cgroups. LXC guys have a lot of influence and drive in this area as well. Also I have been included in a few discussions which concluded that libvirt-lxc will be our #1 choice in the area of containerized applications, as they are the most generic technology we have. Docker.io uses its version of namespaces and everything but I got the feeling they are switching to libvirt-lxc as well so a large piece of cloud will probably follow. In this As Ales said, there is simply too much dust in the air right now, we need to wait for it to settle.
Deferring this one ... Docker seems to rule the world of container technologies. We will take a look at some Docker-DNF integration but it will most likely be on completely different level than what was suggested here.