terraform-provider-lxd
terraform-provider-lxd copied to clipboard
[QUESTION] Is it planned to manage projects through lxd provider
Hi,
LXD Projects (src1, src2) make it possible to manage multiple namespace in one LXD server (e.g. : dev/preprod/prod, or Client1/Client2/Client3 , or proj-1002/proj-2048).
It's seems very useful to separate things, as you may have projects with separated images, networks, profiles and storage volumes. And you are able to separate just images and profiles, or only networks and storages, or any mix of this four elements.
Have you planned to have a "project" resource, and an optional "project" variable in the resources ?
Regards,
Now thinking about it, "LXD projects" are used through a "switch" method... So I think the simpler solution would be to set a "project" variable in the provider definition.
provider "lxd" {
generate_client_certificates = true
accept_remote_certificate = true
lxd_remote {
name = "lxd1-client1"
scheme = "https"
address = "10.1.1.8"
password = "password"
default = true
project = "client1"
}
lxd_remote {
name = "lxd1-client2"
scheme = "https"
address = "10.1.1.8"
password = "password"
project = "client2"
}
}
Projects have to be already set through preseed init before terraform deployement, and if a project come after you just need to add a new remote.
What do you think about that ?
Regards,
As a workaround, you can manually connect and set lxc client on your machine (the machine you're running terraform from), and set project in lxc client config (usually ~/.config/lxc/config.yml). From terraform you then just reference this connection to the remote lxd server. You need to create one connection for each project, so this is far from ideal setup.
This solution requires a lot of "manual" /"semi manual" operations, So yes: very farfrom ideal...
+1 for implementing projects managing
I don't think that the project should be in remote section because resources are binded to the project not to the remote. Just imagine what happened if you will change remote connection settings? I think nothing except for the project value. So, maybe it should be specified as a additional field in all resources? Or maybe it should be represented as additional provider not a remote.
Hi folks,
I have not had time to look into this. If someone else is able to, I would be happy to review.
I recommend reviewing the "project" API to determine the scope/context in which resources can be managed via projects. If a project is scoped during the connection phase, then having it in the "remote" is the best solution.
If it is possible to specify a project during each API call (eg when creating a container, deleting a container, etc), then a project field can be added in each resource. This would allow an admin user to create resources for multiple projects under a single "remote".
Next, if it's possible to use the LXD API to create and manage projects, then support for first class lxd_project
resources can also be created.
Hi folks,
I have not had time to look into this. If someone else is able to, I would be happy to review.
I recommend reviewing the "project" API to determine the scope/context in which resources can be managed via projects. If a project is scoped during the connection phase, then having it in the "remote" is the best solution.
If it is possible to specify a project during each API call (eg when creating a container, deleting a container, etc), then a project field can be added in each resource. This would allow an admin user to create resources for multiple projects under a single "remote".
Next, if it's possible to use the LXD API to create and manage projects, then support for first class
lxd_project
resources can also be created.
Would like to dig into it
I'm also interested in this.
Looks like the project is passed as a URL parameter. This is from lxc network list --debug
:
...
DBUG[08-12|20:57:58] Sending request to LXD method=GET url="https://<lxd_host>:8443/1.0/networks?project=<project_name>&recursion=1" etag=
...
Found the Swagger docs for the API, project
is declared as a parameter in many but not all endpoints.
I believe having it as an argument everywhere it's supported is good, but it may be useful to set it in the provider and use that as a default unless overridden locally to a resource.
This was done in #279.
@c10l @dorkamotorka thank you both for your work on this.