terraform-provider-lxd icon indicating copy to clipboard operation
terraform-provider-lxd copied to clipboard

[QUESTION] Is it planned to manage projects through lxd provider

Open jadjay opened this issue 3 years ago • 9 comments

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,

jadjay avatar May 29 '21 22:05 jadjay

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,

jadjay avatar May 29 '21 22:05 jadjay

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.

matjazp avatar Jun 04 '21 07:06 matjazp

This solution requires a lot of "manual" /"semi manual" operations, So yes: very farfrom ideal...

jadjay avatar Jun 04 '21 07:06 jadjay

+1 for implementing projects managing

opticoder avatar Jul 04 '21 23:07 opticoder

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.

arren-ru avatar Jul 07 '21 08:07 arren-ru

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.

jtopjian avatar Jul 07 '21 16:07 jtopjian

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

arren-ru avatar Jul 08 '21 06:07 arren-ru

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

c10l avatar Aug 13 '21 00:08 c10l

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.

c10l avatar Aug 13 '21 01:08 c10l

This was done in #279.

dorkamotorka avatar Dec 20 '22 08:12 dorkamotorka

@c10l @dorkamotorka thank you both for your work on this.

jtopjian avatar Dec 20 '22 19:12 jtopjian