Primary Groups Proposal

Today CNaaS-NMS has the concept of groups, and a device can be a member of many different groups at the same time. This concept is good for when assigning VXLANs, upgrading devices, syncing devices etc. However, I think it will get too complicated if you want to assign settings or permissions to devices since it's hard to know in what order rules apply and which setting/permission will override. Therefore I  propose we add a "primary" group for each device, and each device will always have exactly one primary group that it belongs to. Settings and permissions can only be applied to primary groups, "secondary" groups can still be used for the same things as before (VXLAN assignment, upgrade, sync).

Configuration

Since groups are today configured in yaml settings, I think we should continue with that pattern. When configuring groups with regexp patterns in a central file it's easy to pre-provision groups for devices that have not been deployed yet so they get the correct settings from the start. An alternative would be to have a field in the database model that you update via API calls, which would make lookups easier but probably confusing for users. A compromise can be to parse primary groups when settings are updated or new devices are added/hostnames are changed, and then save the information in the device model. Another way would be to parse and save in redis cache for fast lookups. Having it in the device model makes it easy to view primary group by just API query a device, but maybe redis cache for primary group can just be appended to device API GET call outputs as well (although it should be made clear in docs this field can not be updated via API PUT calls etc).

If configuring primary groups via yaml settings, I propose a new field in the groups.yaml file that specifies "group_priority": 0-100, where 0 means this group will not be considered for primary group evaluation at all, and 1 is lowest priority, 100 is highest priority. Any devices that does not get a primary group through this group_priority setting will end up in primary group DEFAULT, which can also be used to specify settings and permissions.

We could then allow for a groups/ directory in the settings repo where you have the normal set of files but specifying overrides for primary groups. In the groups.yaml file you could also have fields for which API users or user-groups that should be allowed read or read/write access to that primary group.