Cobbler Inventory: allow users to specify extra groups

[Ty9000]

SUMMARY

Fix for #9419

Adds all rolled up Cobbler variables for a system to the Ansible inventory

Allows a user to specify multiple extra groups to add to the inventory

Fixed a few typos, simplify imports for required libraries

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

inventory/cobbler.py

ADDITIONAL INFORMATION

Tested on Cobbler 3.4.0

[ansibullbot]

cc @opoplawski
click here for bot help

[opoplawski]

Thanks for the contribution. I'm not sure though from first glance how extra_groups is meant to be used. Could you give a specific example? Also, it seems to be tied to want_facts also being set, which isn't mentioned in the doc string.

I also think adding the get_system_as_rendered() call is going to add significant overhead - so I think we will want to add a second want_full_facts or some other mechanism (make want_facts accept full?) to turn it on separately. My timing of ansible-inventory --list without a cache went from 2.9s to 16.5s.

Finally, as implemented the full system info is not cached (doubly important with the added overhead) and in facts breaks the second time it is run with a local cache:

'InventoryModule' object has no attribute 'token'

I think you'll want to move the calls to get_system_as_rendered() into _get_systems so you can cache everything there.

I see how it could be useful for some people though, so it definitely is worth adding.

[felixfontein]

so I think we will want to add a second want_full_facts or some other mechanism (make want_facts accept full?) to turn it on separately.

want_facts is currently a boolean parameter, changing it to a string with choices is dangerous since it's not fully backwards compatible. (Ansible has some magic that will make it mostly backwards compatible, but probably not fully.)

How about adding a new option that determines the level of facts (maybe facts_level with choices minimal, normal, and as_rendered or something like that?) and that will eventually replace want_facts (whose values would map to two specific choices for the new option)? That would also allow to later add even more levels.

[Ty9000]

For extra_groups, the environment I'm in using Cobbler to declare autoinstall_meta key:value pairs in the distros, profiles, and systems for things like branch, environment (test/ops/etc), system_role, profile_role. Declaring the extra_groups allows ansible-inventory to pull those values of as group membership. We have so many systems (like 10,000+) and independent Cobbler installations that using branch, environment, profile_role really helps organize machines into groups, especially since we truly have no other way to categorize machines

Yeah, adding a new option like facts_level would work! Sorry about that! It's my first foray into this kind of thing.

As for the massive increase in timing, just curious how many systems did you have in the inventory and what version of Cobbler? We're kinda tied down a specific version of Cobbler for now and was curious if updates are increasing/decreasing overhead on API calls

Yeah, that's my bad - I didn't test the caching. The environment I'm in doesn't really work with caching of anything. We have so many systems, profiles, and distros that may change in between ansible-inventory runs...

I'll test some stuff out at work on Monday/Tuesday with the caching, fixes, et cetera and bring those home to merge in

[russoz]

hi @Ty9000 thanks for your contribution.

The new feature seems to be fine, but I left some comments on some of the other changes made.

[russoz]

As a personal preference, I think it is clearer what those errors are about when prefixed with socket.. One year from now if I read this code, I would have to go back and forth to the imports to understand what's going on. In this case they are close and it would be very quick, but I think it would be a good practice to be more explicit about it. Just my $0.02

[russoz]

Some required formatting changes, but also a bit of a style suggestion - we could/should be more concise in here.

Suggested change

	- inventory/cobbler.py - fix a few typos, simplify required library imports, request full rendered variables for Cobbler system, allow end user to specify extra groups to add systems to in Ansible inventory, should not change currently expected behavior (https://github.com/ansible-collections/community.general/issues/9419)
	- cobbler inventory plugin - fix typos, simplify required library imports, request full rendered variables for Cobbler system, allow end user to specify extra groups, should not change currently expected behavior (https://github.com/ansible-collections/community.general/issues/9419).

Please refer to the standard formatting for the changelog fragments' entries:
https://docs.ansible.com/ansible/devel/community/development_process.html#changelogs-how-to-format

The outcome of this changelog fragment can be seen in the collection changelog:
https://docs.ansible.com/ansible/latest/collections/community/general/changelog.html

[russoz]

Not sure I like calling the attribute c. I am fine using these shortcuts in very localised contexts, specially for short-lived vars or comprehensions, but when it comes to actual attributes it is a good practice to have meaningful names.

Someone not familiar with the code, one year from now, should be able to read one of the methods below without having to go back and forth within the code to understand what c means. connection? cache? cobbler? compute?

[felixfontein]

Ping @Ty9000

needs_info

[Ty9000]

Ping @Ty9000

needs_info

Sorry! I'm on a work trip and won't be back home for a couple more weeks... This is still on my radar and I'll get some updates pushed out mid-February, if that's okay

[felixfontein]

No worries, it's mainly to make sure that PRs aren't completely abandoned :) (The bot will auto-close if nobody reacts in 2-3 months if the needs_info label is there.)