Bug 1024773 - [rfe] [plugins] install and update systemd machine containers
[rfe] [plugins] install and update systemd machine containers
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
20
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-30 07:55 EDT by Jóhann B. Guðmundsson
Modified: 2014-11-12 08:39 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-12 08:39:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jóhann B. Guðmundsson 2013-10-30 07:55:29 EDT
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:
Comment 1 Jan Zeleny 2013-10-30 08:35:19 EDT
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.
Comment 2 Jóhann B. Guðmundsson 2013-10-30 09:37:53 EDT
(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.
Comment 3 Jan Zeleny 2013-10-30 09:49:40 EDT
(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 ...
Comment 4 Ales Kozumplik 2013-10-30 10:05:14 EDT
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.
Comment 5 Jóhann B. Guðmundsson 2013-10-30 10:15:09 EDT
(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 ;)
Comment 6 Ales Kozumplik 2013-10-30 10:16:49 EDT
(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?
Comment 7 Jóhann B. Guðmundsson 2013-10-30 10:33:30 EDT
(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 :)
Comment 8 Jan Zeleny 2013-10-30 10:57:57 EDT
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.
Comment 9 Jan Zeleny 2014-11-12 08:39:13 EST
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.

Note You need to log in before you can comment on or make changes to this bug.