I’m trying to automate the creation of host groups, and to avoid to forget some hosts that would be in zero groups, I created a dust collector I called ungrouped_hosts.
I manually added created assign statements like :
AND
host.groups != group01
host.groups != group02
…
in the hope that every host that would not be in any of these groups would pop in this final group.
This was NOT working (lots of grouped hosts (thus undue) were appearing there, BUT, at the moment I changed one single statement in the definition of this dust collector, its content got correct.
I’m understanding this as a proof I need someone to tell me in which order these groups are evaluated, and also to confirm that this evaluation is NOT dynamic.
Is there a way to debug this to see how these hostgroups are built?
I believe it’s lexical. I used groups in the past for role management and resorted to naming them zzz_auth_role and put them at the end of my groups.conf.
This way I made sure that the application and administrative groups were created before i used them to apply the groups that I used in the roles.
So I would rename your ungrouped_hosts to zzz_ungrouped_hosts define it at the end after the other groups just to make sure.
In regards to the configuration validation?
Actually I don’t know. But as we mix&match Director and config files I guess there is some “mechanism” that does something in regard to the object loading order.
)