The problem with “old style groups” is that they are missing the possibility to define unique_id → therefore cannot be managed from GUI → therefore cannot be assigned Areas and Labels…
So… we’re in a mess, where “new style groups” can be managed from GUI, but can’t have an empty list of entities, while “old style groups” can have an empty list of entities, but can’t be managed from GUI. None of the group styles is powerful enough to have it all.
Therefore → the feature request → make the “new style groups” more powerful → allow for an empty list of entities.
What would you get with an empty entity group? It would be useless as you can’t dynamically add or remove entities from new groups. It’s been stated by the core team that editing and adjusting configurations will never be added to new school groups. So all you’d get out of this FR is an empty group you can do nothing with.
I could see Frenck potentially adding the ability to adjust groups in spook, that’s about it.
As a sidebar, I use labels for this. No need for group management or to worry about empty groups. Just use a label to identify groups of entities. Spook can even add/remove labels (which will also likely not make it’s way to core).
No, you can already adjust configurations for old style groups with group.set. That service will not be added to new style groups, but it’s a moot point because of your previous points.
Not sure why that is a requirement, but maybe you’re missing my point. I’m saying to completely remove old-school groups and go with labels. I did that when labels were introduced and it’s a much easier process now.
Well, in this particular case, I don’t need to manage group members via services, nvm then.
Well, any useful change I do, I’d like to be able to track with git. Creating a group in YAML allows me that. I cannot add labels to entities in YAML, therefore I cannot DIFF/BLAME/COMMIT changes made with labels, therefore → labels are inferior to groups.
Cool, as soon as I can manage labels in yaml. Until that, keep old+new style groups (as they both have uses, even though none is perfect).
Please point to where I said the feature request was invalid. I really wish you’d stop assuming this all the time with every conversation. Asking questions is part of the discussion.
I was identifying your use case which your FR did not spell out. The only use case I thought of, was for dynamic groups, which would make the FR require a second FR.