Description of problem: When dealing with multiple containers we should allow administrators to set alias for components which will allow them to easily identify multiple company's they are hosting/running containers for in their infrastructure. Something in the form of ... systemd-nspawn -xxx /containers/www.example.com/ -M www.example.com -A "Red Hat" and or machinectl xxx -A "Red Hat" which would yield MACHINE CONTAINER SERVICE Alias www.example.com container nspawn Red Hat with multiple containers this for example would look like... MACHINE CONTAINER SERVICE Alias www.example1.com container nspawn Red Hat www.example2.com container nspawn Red Hat www.example3.com container nspawn Red Hat www.example1.org container nspawn Fedora www.example2.org container nspawn Fedora www.example3.org container nspawn Fedora Followed by something like machinectl list -A Fedora MACHINE CONTAINER SERVICE Alias www.example1.org container nspawn Fedora www.example2.org container nspawn Fedora www.example3.org container nspawn Fedora This would allow administrators to set all kinds of infrastructure policy's/code/scripts surrounding the "Alias" as opposed to the domain name. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
You want some kind of grouping here? The term "Alias" doesn't imply grouping?
Tag/alias/grouping basically something that says this container belongs to "X". If people want to charge or otherwise monitor resource usage on containers they need a way to see a) which customer/group the container belongs to and b) how much resources have been allocated to him.
Wouldn't it suffice if we support glob-based wildcard matching when listing machines, and then leaving it to the administrator to name his machines "customer1-foo", "customer1-bar", "customer2-waldo" so that he can match: "machinectl list-machines customer1-*" or so? That sounds a lot more powerful to me.
(In reply to Lennart Poettering from comment #3) > Wouldn't it suffice if we support glob-based wildcard matching when listing > machines, and then leaving it to the administrator to name his machines > "customer1-foo", "customer1-bar", "customer2-waldo" so that he can match: > "machinectl list-machines customer1-*" or so? That sounds a lot more > powerful to me. Not really ( all thou it makes sense to support that as well ) and I know you dont like hearing this but administrator would name the containers or the machines as you like to call it by their fqdn ( even application containers ) or by some other factors certainly not by their customer name which only work internally in small company's and small businesses and for home users . "Alias" is bad word "Label" is probably more appropriate since it could be used for whatever naming scheme is being used in the relevant infrastructure and I think we need to add that field to the entire type units we have and list it under the documentation field for services in status output if filled out. MACHINE CONTAINER SERVICE Label <-- www.example1.com container nspawn Red Hat And for application containers example.service - example service Loaded: loaded (/usr/lib/systemd/system/example.service; disabled) Active: active (running) since Fri 2013-09-13 06:33:25 GMT; 2s ago Docs: foo Label: Red Hat <-- Process: ... Now if I weren't technology challenged coding monkey which limits me to provide feedback only, I would have called the command containerctl which clearly identifies for the administrators they are working with containers and I would have it output like this when ran ( and arguably add to that the resource assignement ) CONTAINER Type SERVICE Label <-- www.example1.com machine nspawn Red Hat httpd application nspawn Red Hat contained-gnome-application application nspawn Gnome ....
Fedora is not the place where systemd development is happening. Please report your enhancement request to https://github.com/systemd/systemd/issues . Thank you for understanding.