Hi, I believe the right layer of abstraction is present in the SG manager (and yes, we should remove isVMWare checks). This abstraction works at the ‘policy’ level: which IP/VM is allowed to talk to which VM/IP. This policy is translated into a concrete implementation by the resources. So I don’t like the idea of hypervisor-specific gurus (network gurus should be agnostic of the hypervisor)
From: Jeff Hair <j...@greenqloud.com<mailto:j...@greenqloud.com>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Date: Monday, March 24, 2014 at 9:12 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Subject: [PROPOSAL] More Flexible Security Group Implementation 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
