Disassociate between interface FHRP group assignment options and interface IP address

[hzc12321]

Proposed Changes

In other words, deprecate "only FHRP groups with a related IP address assigned are displayed as options" when assigning FHRP groups to interfaces

I'm using FHRP groups to represent the mapping between F5 load-balanced service VIPs and the actual servers behind it, and noticed this behaviour complicated everything.
Reference :

I have encountered a similar issue, but this : https://github.com/netbox-community/netbox/issues/8435 explained it. Seems like once the interface has an IP address assigned, only FHRP groups with a related IP address assigned are displayed as options. While this makes sense in some use case, it becomes an obstacle for certain use cases.

In my use case, the FHRP group maps between a load balanced VIP and the real IPs on the VM interfaces. Once I have the FHRP group ready, I must first assign FHRP group before assigning real IP to the interface, if not, and if the VIP and real IP do not belong to the same subnet (related), the FHRP group option will disappear.

I would suggest this behaviour to be removed, as it is not a globally applicable scenario, it brings inconvenience to other use cases while bringing convenience to certain use cases. Plus, the purpose of "Avoiding the user from having to select from hundreds of potential groups" is already achieved by allowing user to type and quick search within the column.

Originally posted by @hzc12321 in #18696

Justification

It assumed too much details about the use case, and brings restrictions based on that assumption, but the assumption is not globally appplicable and unnecessary.

It can get worse :
Whenever when there is a need to assign a new FHRP group to an interface with existing IP address and FHRP group assigned, I have to first unassign all the IP addresses which are not under the same parent prefix as the new FHRP group. Then, after assigning the FHRP group to the interface, assign all the IPs back to the interface.

Due to this behaviour, issues like these are likely to be raised repeatedly by different persons over time:
#8435
#18696

It's not a must that each interface's IP address is under the same parent prefix as the FHRP group's VIP, there could be additional mechanisms like NAT or ARP proxying in the middle. Plus, it occurs frequently.

Impact

• Users are now free to decide which FHRP group to assign to an interface, without considering IP addresses assigned on that interface.
• In case if there are hundreds of FHRP groups, the user can type and quick search during FHRP group assignment, and therefore does not affect the overall usability.

[arthanson]

@hzc12321 can you please re-open this as a feature request as this is really a change in existing functionality, it is also not really clear what the issue / proposed solution is here.