cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hair <j...@greenqloud.com>
Subject Re: [PROPOSAL] More Flexible Security Group Implementation
Date Tue, 25 Mar 2014 09:59:14 GMT
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.Vittal@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 <jeff@greenqloud.com<mailto:jeff@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message