Hi, Currently the security group manager has a very specific implementation that requires an agent running on the other end. This works for KVM but not for other hypervisors such as VMware. The validation mechanisms are also very tightly coupled to the large methods in the NetworkManager and UserVmManager.
I'd like to propose a more flexible way of handling security groups, perhaps called SecurityGroupGuru. Major points: - Instead of having hard checks like "if (isVmWare) throw InvalidParameterValueException" when it comes to security groups, the various managers would loop through the set of security group gurus until they find a guru that supports the desired configuration (combination of hypervisor, zone type, network type). - The SecurityGroupManagerImpl will now send jobs off to the SecurityGroupGuru to handle, instead of handling the job itself. For example, a KvmSecurityGroupGuru would handle the jobs as they are now. A new VmwareSecurityGroupGuru could be implemented for VMware, etc. The main desire for this proposal is to to allow extensible security group implementations that don't have to override extremely large methods to change their behavior on a few lines. Some possible use cases of this include: - Changing security group behavior. Instead of having the security groups on a physical host, they could be put on a virtual router. - A foundation for security groups in isolated advanced-mode networks. - Organized, maintainable implementations of security groups for different hypervisors. Thanks, Jeff
