Bug 1000200 - RFE: introduce containerctl
RFE: introduce containerctl
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: systemd-containers
  Show dependency treegraph
 
Reported: 2013-08-22 18:44 EDT by Jóhann B. Guðmundsson
Modified: 2013-09-13 03:31 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-12 15:18:42 EDT
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-08-22 18:44:20 EDT
Description of problem:

I think it's unavoidable not having a containerctl command which will create delete, assign and alter container resource as well as to allow container administrator(s) to administer an container, on the container host server ( as in outside the container itself ).

An wrapper on top of chroot I guess would go far I suppose ( ( or intergrade chroot like solution ), to handle administrative tasks 

For example to "log into container"

"chroot /containers/container01.example.com/ su - root"

would become 

"containerctl container01.example.com"

Adding the user test in an OS container from the host running all the containers

"chroot /containers/container01.example.com/ su - root -c ". ~/.bash_profile; adduser test"

would become 

"containerctl container01.example.com adduser test"

etc..

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Zbigniew Jędrzejewski-Szmek 2013-08-22 20:55:34 EDT
I think the master plan calls for adding this functionality to machinectl.
Comment 2 Jóhann B. Guðmundsson 2013-08-23 07:14:53 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> I think the master plan calls for adding this functionality to machinectl.

<shrug>

Adding this to machinectl is like adding an elevator to an outhouse. 
it just doesn't belong...


This whole new naming scheme ( machine/slices ) has never sat right with me and is a mess, confusing to administrators and violates the clear,clean,self explanatory naming scheme of existing unit types in systemd and the concept of containers in general.

"machine" should have been called os and slices should have been called container and the unit end with a .container 

The naming scheme should have been..

os.container ( as opposed to machine.slice )
application.container ( this should have been introduced in the design from the start )
system.container ( as opposed to system.slice )
user.container. ( as opposed to user.slice )

We are not dealing with resources slices we are dealing with containers and operating system and application stored within those containers. 

It's not to late at this point in dismissing this new naming scheme and take up something that more accurately and sanely describes what users are working with and what this actually is and have it aligned with the clear,clean,self explanatory naming scheme of existing unit types.

So people let's not be way of base here and repeat the same mistakes as the gnome developers did with their disk utility by calling it palimpsest as opposed to gnome-disk-utility from the start.
Comment 3 Kay Sievers 2013-08-23 07:40:14 EDT
(In reply to Jóhann B. Guðmundsson from comment #2)

> We are not dealing with resources slices we are dealing with containers and
> operating system and application stored within those containers. 

This is not true, we are only dealing with a defined set of
*resources* here. Slices are *partitioning* sets, not a container.
Slices can be arbitrarily stacked, users have a slice, the default
system has a slice, and so on.

But anyway, this is a bug tracker, please discuss such things on the mailing
list and not here.
Comment 4 Lennart Poettering 2013-09-12 15:18:42 EDT
We already have machinectl, and we should make sure we don't reimplement virsh/libvirt...
Comment 5 Jóhann B. Guðmundsson 2013-09-12 16:22:53 EDT
to me machinectl indicates that your are dealing with physical machines hence the suggestion to make it clear that you are altering "containers" and I dont think we can avoid implementing own containers command as opposed to reusing virsh/libvirt ( atleast not without re-naming it to avoid confusion with containers and virtual machines ) 

And I thought Red Hat would have seen businesses opportunity making a move at replacing AIX on Power7 or work with IBM in that regard ( and or coming up with a similar license structure around unlocking resources in hw/containers ) and there they would not be able to re-use virst/libvirt but yeah you are probably right that's just me being stupid and honestly why should I care in the first place....
Comment 6 Lennart Poettering 2013-09-12 17:40:20 EDT
(In reply to Jóhann B. Guðmundsson from comment #5)
> to me machinectl indicates that your are dealing with physical machines
> hence the suggestion to make it clear that you are altering "containers" and

Well, machinectl is supposed to be a generic term that covers both "containers" and "VMs". The latter covering KVM and friends, the former covering nspawn/lxc and friends.

Also see:

http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/

which clarifies the vocabulary we agreed on within the systemd project.
Comment 7 Jóhann B. Guðmundsson 2013-09-13 03:31:08 EDT
(In reply to Lennart Poettering from comment #6)
> (In reply to Jóhann B. Guðmundsson from comment #5)
> > to me machinectl indicates that your are dealing with physical machines
> > hence the suggestion to make it clear that you are altering "containers" and
> 
> Well, machinectl is supposed to be a generic term that covers both
> "containers" and "VMs". The latter covering KVM and friends, the former
> covering nspawn/lxc and friends.
> 
> Also see:
> 
> http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/
> 
> which clarifies the vocabulary we agreed on within the systemd project.

Which is fine I guess if you have separated vm's and container commands and the machinectl list both but still I think it would be confused with actually physical machines. 

Was there any administrators present when this was decided or was this more like what we are all to familiar with managers when they sit at table and have an idea which is nothing more then something that looks great on paper but turns out to be crap on field? 

In anycase this seems to have been set in stone I guess and we should not be using bugzilla to discuss this.

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