Red Hat Bugzilla – Bug 1000200
RFE: introduce containerctl
Last modified: 2013-09-13 03:31:08 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"
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"
"containerctl container01.example.com adduser test"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I think the master plan calls for adding this functionality to machinectl.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> I think the master plan calls for adding this functionality to machinectl.
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.
(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.
We already have machinectl, and we should make sure we don't reimplement virsh/libvirt...
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....
(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.
which clarifies the vocabulary we agreed on within the systemd project.
(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:
> 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.