Implement ansible module for management of libvirt volumes

[NK308]

SUMMARY

This PR adds a module to create, delete and modify libvirt volumes.

This PR is based on the fork which was subject of #45

ISSUE TYPE

• New Module Pull Request

COMPONENT NAME

virt_volume

ADDITIONAL INFORMATION

Some of the code of the new ansible module as well as parts of the code of virt_pool, have been refactored to module_utils to reduce redundancy.
For now I have only tested the simple creation und deletion of storage volumes, so there might some more testing be needed.
For now I didn't do much more, compared to #45, than bringing the branch up to date with the main branch, including the adoption of changes in the code and doc style from the other modules.

[NK308]

The integration tests now fail because of ... keyboard interrupt? How?

[Andersson007]

@NK308 hello, i wonder if we can remote those remote targets

[Andersson007]

@NK308 thanks for the PR
I would separate the code:

1. You refactor the code in one PR
2. Then you add the module in another PR or wise versa

It's easy to make a mistake and imo not a good idea in general to mix refactoring and new features in a single PR.
Hence, i'm suggesting splitting the PR.

cc @csmart

[Andersson007]

Suggested change

	class LibvirtConnection(object):
	class LibvirtConnection(object):

don't you import this class from module_utils.pool?

[NK308]

The imported class is not called LibvirtConnection in the namespace of plugin.modules.libvirt which is something I adopted from https://github.com/flagbot/community.libvirt/tree/feature/virt_volume.

[Andersson007]

Suggested change

	from ansible_collections.community.libvirt.plugins.module_utils.pool import LibvirtConnection as PoolConnection, HAS_VIRT, HAS_XML
	from ansible_collections.community.libvirt.plugins.module_utils.entry import EntryNotFound
	from ansible_collections.community.libvirt.plugins.module_utils.pool import LibvirtConnection as PoolConnection, HAS_VIRT, HAS_XML
	from ansible_collections.community.libvirt.plugins.module_utils.entry import EntryNotFound

I think this should be moved up to line 131

[NK308]

@NK308 thanks for the PR I would separate the code:

1. You refactor the code in one PR

2. Then you add the module in another PR or wise versa

It's easy to make a mistake and imo not a good idea in general to mix refactoring and new features in a single PR. Hence, i'm suggesting splitting the PR.

cc @csmart

Hi
I the reason, why the new module and the refactoring are mixed up here is, that I based my branch on a pre-existing branch, which came with this intermixing of new features and refactoring, and I tried to keep changes to a minimum while resolving the conflicts between that branch and main.
I probably would have done some things different, if I wrote the module all by myself.

[NK308]

About the refactoring topic, if I'm gonna split the refactoring off this PR anyway...
This collection seems to contain a lot of redundant code since each module is basically a wrapper around a class from the libvirt python bindings. Maybe all of the modules should be refactored together, introducing some inheritance?

The coding style seems to be a bit weird in general. The find_entry() function for example is two completely different functions in one:
@overload def find_entry(self, entryid: str) -> virSomething def find_entry(self, entryid: int = -1) -> list[virSomething]So there is actually no reason, to not split that into two different functions.
Also the naming is a bit irritating since there in most modules, there are at least two classes available with a function named find_entry, which are not related but basically do the same, with different return types. Having the same name would make sense if the classes inherited the method from the same super class, but since they don't, names like find_volume, find_pool, find_domain, etc. would be a lot more self-explanatory.

Also it seems very arbitrary, which methods take the python wrapper of some libvirt object, or it's name (and call find_entry by itself to get the wrapper). I think, it would be better coding style, to have a wrapper class for all the classes from the libvirt python-bindings, so that each of the libvirt objects gets wrapped into its own object instead of writing classes, consisting only of methods, which could as well be standalone functions.

I'm not sure, how much of that might be prevented by the requirement to keep compatibility down to python2. Things like generic classes surely won't work.

[NK308]

@NK308 hello, i wonder if we can remote those remote targets

I'm not sure about that. In some of the previous commits, there was an actual error message, which showed an actual problem with an integration test, which dissappeared after I fixed it. And this error only showed on the Remote RHEL targets for some reason, I don't understand.

[NK308]

"no connection driver available for qemu:///system" is a new error, and I'm not able to tell, why it starts showing up exactly now, and not earlier.

[Andersson007]

I'm unfortunately completely unfamiliar with the technology and have no idea about why the tests fail
@csmart @drybjed @odyssey4me any thoughts?

[Andersson007]

@NK308 i took a quick look, i see you test on very old distros, how about just testing only on ubuntu 24.04 if it makes sense?

[NK308]

@Andersson007 The issue seems to be very specific to the RHEL remote targets, even the current version, while older versions of other operating systems don't seem to cause any problems.
I was also assuming, a PR has to pass those targets to be accepted to a collection in the community namespace.

[Andersson007]

@Andersson007 The issue seems to be very specific to the RHEL remote targets, even the current version, while older versions of other operating systems don't seem to cause any problems. I was also assuming, a PR has to pass those targets to be accepted to a collection in the community namespace.

@NK308 my comment is not related to the failures, i just think it's an extra thing and there's no such a requirement to test against them. I'm not familiar with the technology though and I don't know if it's distro dependent or not.
If it is, it makes sense to test against several relevant distros but I guess it doesn't make sense to test on not supported ones.

[NK308]

I now have removed the OS specific variables from the integration tests, if that's what you meant. The remaining operating systems represented in tests/integration/targets/virt_volume/vars are actually not yet end of life, despite being old, or at least still receive some kind of extended support.

[Andersson007]

@NK308 how about removing RH 7 and updating Ubuntu 16 to 24.04 ?

[NK308]

Those versions are not end of life yet, and servers can still receive extended support, as stated here https://en.wikipedia.org/wiki/Ubuntu_version_history and here https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux.
That's why I don't consider it a good idea to remove something related to those system.

[csmart]

Hi @NK308 thanks very much for reviving this, I'll take a look and put in any comments in line.