Bug 1000200

Summary:	RFE: introduce containerctl
Product:	[Fedora] Fedora	Reporter:	Jóhann B. Guðmundsson <johannbg>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	johannbg, lnykryn, msekleta, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-12 19:18:42 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1000189

Description Jóhann B. Guðmundsson 2013-08-22 22:44:20 UTC

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-23 00:55:34 UTC

I think the master plan calls for adding this functionality to machinectl.

Comment 2 Jóhann B. Guðmundsson 2013-08-23 11:14:53 UTC

(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 11:40:14 UTC

(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 19:18:42 UTC

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 20:22:53 UTC

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 21:40:20 UTC

(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 07:31:08 UTC

(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.