When using LXD I usually open several ssh connections in order to work inside different containers at the same time, like an HAProxy container, a WP container and a MySQL container.
Today I started playing with lxd projects for the first time and I immediately noticed that new ssh connections inherit the current project, making it very awkward (at least in my scenario) because HAProxy leaves in the default project, WP lives in the client’s project and mysql lives in the DB project, hence each time I want to SSH to the host and exec a container I get an error, bacause I am “jailed” within the last used project.
Easy enough to fix, just switch to the other project… yes, but then when I go back to the other SSH window to work back on the WP container, the project has been changed too for the other window, and so on and so forth… you get the idea…
Open an SSH connection to your host
Create a new project
Switch to the new project and create a new container on the new project
Open a second SSH connection
Run lxc ls
The second connection will show containers of the new project (expected was lxc would list the containers on the default project)
Now switch to the default project on your second ssh connection.
lxc ls will list all the containers in the default project.
Now go back to your initial SSH connection and run lxc ls, the containers on the default project will be listed, even if that connection was supposed to be on the new project.
I’m missing a command to show the current project I’m “jailed in”
I think a command to list all containers in any given project or in all projects of a host would also be great, in which case a new column could be added to lxc list to show the project a container is in (just like it tells you the node of a cluster a container is in)
The possibility to define projects as tags, so one container can be part of several projects, for example a container for MySQL could live both in the “DB” project but also in the “customer_001” project.
The ability to limit the network reach to only other containers within the same project(s), so all my “customer_001” containers can see each other but any containers on “customer_002” are unreacheable.
Take a look at
~/snap/lxd/current/.config/lxc/config.yml
the project is just a remote property. You can get lxc project switch functionality by editing this file.
lxc project list indicates the current project. lxc info also shows you what project was used.
lxc list --project NAME
Projects aren’t tags. As projects can have different feature sets and soon will have quotas/restrictions too, you can’t have a container be part of multiple projects.
Unlikely to be done with current networking, but we do plan on adding support for virtual networks in projects (backed by OpenVswitch/OVN).
lxc project list indicates the current project.
I completely missed the “(current)” tag in the list, thanks for the pointer.
How can I list all containers in all projects?
lxc info also shows you what project was used.
Sorry, I don’t understand this.
Projects aren’t tags. As projects can have different feature sets and soon will have quotas/restrictions too, you can’t have a container be part of multiple projects.
OK, I really didn’t understand the scope of projects, at a first glance it looked to me like a housekeeping tool, now I see it goes far beyond just that.
Anyway, maybe you could inherit/apply a container’s properties from the first project it is assigned to/born from and ignore the following ones from the settings/configuration perspective? That would improve the housekeeping side of things while not interfering with the rest.
Unlikely to be done with current networking, but we do plan on adding support for virtual networks in projects (backed by OpenVswitch/OVN).
Wonderful! what does that mean for FAN networking clusters?
And a last question: Is there any way I can improve or change the behavior of my ssh client in order to get connection dependent/connection aware behavior so each connection is aware of the project it is working within but remains independent from changes made on other connections?
stgraber@castiana:~$ lxc info | grep project:
project: default
There is no way to automatically list all containers for all projects, you’d need to iterate through the projects yourself.
For the SSH case, not really, you could set LXD_CONF to different values for each client through bashrc/profile maybe, that would give them a completely independent lxc config (also means completely separate set of remotes and aliases though).
Projects are basically a pretty simple feature; you get in some db tables a priject id, with each user there is a field for each ‘remote’ (local LXD server is just special kind of ‘remote’) configurated in the config.yaml giving the default project, and if this field exists in the user specific config file, db data is filtered accordingly.
this (undocumented and unsupported) query explains it well:
lxd sql global "select c.name, p.name from containers c join projects p on (c.project_id = p.id)"
If the LXD_CONF env variable allows to switch the configuration directory as said by @stgraber, you could indeed have 2 connections to your host with the same user ID having 2 different projects…I have never tested it myself, and I know for sure that SNAP is not kind with environment variables filddling. Try it, report if it does not work.
As of project ‘properties’, as such, the projects tables in the LXD db has 3 fields, id, name and description, so they have no ‘properties’, really. What’ s more interesting is to know all tables that have a ‘project_id’ field, and so can be managed for a given projects. AFAICT containers, images, profiles and storage volumes can be linked to projects. There is also a table to store additional config keys for projects, that you can see with lxc project show project-name. From reading LXD code, there don’t seem to exist any hidden feature outside of what you can see yourself.
Edit; I posted that ‘basically projects is a simple feature’. I should have written more precisely ‘conceptually projects is a simple feature’. My first expression seemed to imply that this feature was pretty easy to implement, that’s not what I was thinking.
Holy Wakamole! That was enlightening… thank you very much @stgraber and @gpatel-fr
While I perfectly understand why projects as tags makes unclear sense in the great scheme of things, I can now play with it on my own and tweak it to my needs.