Hi, If the isVmWare checks are removed, what would they be replaced with instead? Would it be an additional method in the Security Group Manager?
On Mon, Mar 24, 2014 at 5:40 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > 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 > >
