Hi all,
Don’t know if it’s interesting or not but I started a small project GitHub - kmpm/ansible-incus where I have begun to completely port the ansible lxd stuff to incus.
There is not much more than a name change and removal of some snap stuff yet.
I had an itch to scratch in that I wanted to test an ansible role using molecule and incus (easier than docker if systemd is involed according to me).
The work I have done in this project works if I use the delegated driver for molecule together with this hacked module.
Is this, incus modules for ansible, worked on elsewere?
Is my work useless because other work is way ahead?
… and similar questions.
I haven’t found anything else and will keep tinkering on this code, if no one shows another project, with a future goal of trying to get it included in the ansible community.general collection.
I’m not aware of anyone currently working on this.
A shortcoming of that module on LXD in the past was that it would directly talk to the local API and therefore didn’t really support dealing with clusters, remote servers, …
Something that may be worth considering is to take an approach similar to the incus connection plugin and interact with the CLI tool rather than directly go over the API.
This would then get you easier support for remotes, projects, authentication, … and also some side benefits like getting to use the keep-alive support that was recently added to the CLI client.
You can either do that by directly driving the normal CLI commands or if you want to keep control over the API, you could wrap incus query which does get you direct API access but still gets to at least use the user defined remotes and authentication bits.
I think an alternative to this module is also to go with Terraform instead for the initial instance, volume, … creation and then use Ansible to deploy the actual workload inside of the resulting instance (through the connection plugin). But I don’t see a problem in having Ansible be able to handle it all either.
Hi and thanks,
I would rather not have to use (and learn) yet another tool like Terraform even though it’s not that hard to learn.
Basing on incus query instead of direct API sounds as an interesting and doable approach.
I will investigate further.
I would rather not have to use (and learn) yet another tool like Terraform
For what it’s worth, as someone who started out using Salt and then learned Ansible (both what you might call “configuration management tools”), I was also skeptical of Terraform at first, but after trying it I have to say that it’s far more suitable for the deployment part than any of the other tools mentioned, whether you’re deploying to the cloud, VMware, OpenStack or (probably, haven’t tried yet) Incus.
As for setting up the systems and continually checking their state however, Ansible or similar tools are still the way to go, and this is definitely out of scope for Terraform.
Also, note that Terraform was recently forked to OpenTofu, so you may want to consider using that instead for licensing reasons.
@baleygr, thanks for your input. Didn’t know about OpenTofu.
But, my main concern for the moment is not to actually deploy server for anything but testing other ansible roles and collections where I would like to run systemd services and so far I haven’t found a great way of doing that where I also can run integration tests of, for example, how the kea DHCP server behaves running under systemd. And yes I could do that with terraform as well but why not incus, how hard could it be .
Hi @stgraber,
I have played around with various method of using the CLI and either 1 of 2 issues always annoys me.
The normal CLI commands are not consistent in the output format. Yes list can generate for example JSON output that is easily parsable but not create, info, start, stop or any of the others (as far as I have found). Parsing stdout and stderr using a undocumented format is not something I would consider fun or reliable.
I have to parse stderr if I call incus query on something as simple as incus query /1.0/instances/mycontainer?project=default if the instance does not exist to figure out what have happened. On calling the API directly I would get "error_code": 404 in the response and be done with it.
I really like the idea of using the CLI tool to deal with remotes, projects etc but I don’t know whats worse. Doing remotes, project, authentication once over the API or do some creative parsing of undefined output that is likely to break for every different call. Even the terraform provider for incus uses the API.
Both methods (commands / query) have their week point in having to parse stderr.
Is the output from the CLI commands stable, predictable and documented somewhere other than in code?
Will they never be translated depending on locale?
I haven’t been able to find any answers to these questions but I might have missed something completely.
You might want to fix community.general/plugins/connection/incus.py.
That one will, for example, not detect instance not found correctly.
The code looks for if stderr == "Error: Instance not found\n" but the format returned
by the CLI looks like Error: Failed to fetch instance "sadf" in project "default": Instance not found\n
Don’t know how you want to deal with it though since it’s not using query --raw.
I would try to make a PR but I don’t know how you would like to have it fixed.
This is great!
I would say using terraform could provide the advantage over ansible e.g
terraform plan to see impact of your changes
manage the state easily vs ansible.
way easier to parameterize resources for your deployment and you don’t have to manage an inventory
Perhpas if there would be interest i could look at making a Terraform provider
.