On Jan 6, 2014, at 2:03 PM, Chris DeRamus <[email protected]> wrote:
> Hey that's great news, thanks for providing this information sebgoa. This > will definitely make things a bit easier. > I also have the missing methods for the cloudstack driver in a local branch but I did not push them cause they lack test/fixtures. -sebastien > > On Mon, Jan 6, 2014 at 7:57 AM, sebgoa <[email protected]> wrote: > >> >> On Dec 30, 2013, at 9:47 PM, Chris DeRamus <[email protected]> >> wrote: >> >>> I propose the following methods for security group management to be >>> promoted and be a part of the standard / base compute API. >>> >>> * ex_list_security_groups -> list_security_groups() >>> >>> Returns a list of class SecurityGroup >>> >>> * ex_create_security_groups -> create_security_group(name, **kwargs) >>> >>> We will use keyword arguments for this call as there are subtle >> differences >>> between the providers (eg: groups within Amazon VPCs) >>> >>> * ex_authorize_security_group_ingress -> >>> authorize_security_group_ingress(security_group, security_rule) >>> >>> Creates an ingress security group rule for a particular security group >>> using a combination of protocol, to/from ports, and IP ranges or user >> group >>> pairs. >>> >>> * ex_authorize_security_group_egress -> >>> authorize_security_group_egress(security_rule) >>> >>> Creates an egress security group rule for a particular security group >> using >>> a combination of protocol, to/from ports, and IP ranges or user group >>> pairs. This will be used by both Amazon and CloudStack as OpenStack does >>> not support egress rules. >>> >>> * ex_revoke_security_group_ingress -> >>> revoke_security_group_ingress(security_rule) >>> >>> Revokes an ingress security group rule for a particular security group >>> using a combination of protocol, to/from ports, and IP ranges or user >> group >>> pairs. >>> >>> * ex_revoke_security_group_egress -> >>> revoke_security_group_egress(security_rule) >>> >>> Revokes an egress security group rule for a particular security group >> using >>> a combination of protocol, to/from ports, and IP ranges or user group >>> pairs. This will be used by both Amazon and CloudStack as OpenStack does >>> not support egress rules. >>> >>> * ex_delete_security_group -> delete_security_group(security_group) >>> >>> This will remove a security group using the ID which works across all >>> providers. >>> >>> * ex_delete_security_group_by_id -> >>> delete_security_group_by_id(security_group) >>> >>> Amazon and CloudStack support removing a group by the name or the ID >> which >>> are mutually exclusive. We will support deletion using either. >>> >>> * ex_delete_security_group_by_name -> >>> delete_security_group_by_name(security_group) >>> >>> Amazon and CloudStack support removing a group by the name or the ID >> which >>> are mutually exclusive. We will support deletion using either. >>> >>> Supporting these calls means that new "SecurityGroup" and >>> "SecurityGroupRule" classes which represent security groups and >>> ingress/egress rules must be added. >>> >>> The proposal for these methods and classes are available as a gist via >>> https://gist.github.com/cderamus/8182092 >>> >>> Currently, this functionality is already implemented as the >> aforementioned >>> extension methods in the following drivers: >>> >>> * CloudStack >>> * OpenStack >>> * EC2 >>> >>> To preserve backward compatibility, we should also modify existing >>> extension methods to call new methods and emit a deprecation warning. >>> >>> *Open questions* >>> >>> There are some differences between the various providers that will make >>> this a bit complex. Here's some of the issues that I foresee and welcome >>> feedback. >>> >>> 1.) Listing security groups for a particular node/instance becomes >>> interesting. OpenStack has a specific call to list the security groups >> for >>> a particular node which is already implemented in the driver. CloudStack >>> appears to allow it using a filter when listing security groups and >> Amazon >>> security groups can be applied to both a node, and in the case of a VPC, >>> they can be applied to a particular network interface using the >>> ModifyNetworkInterfaceAttribute call. There's really no clean way to >>> support this so my guess is we should keep ex_ calls within the drivers >>> themselves for this type of functionality. Thoughts? >> >> Hi, you can list security groups for a particular instance in CloudStack >> using the virtualmachineid argument: >> >> >> http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/listSecurityGroups.html >> >> >>> >>> 2.) Security group rules git a bit dicey and I'm not sure how to best >>> tackle the differences. Amazon/OpenStack are virtually identical and use >>> from/to ports, IP protocols and CIDR ranges or user group pairs for the >>> source. They use -1 to denote all protocols and if there is an ICMP type >>> the type in question is put into the from/to port values. CloudStack >>> supports TCP/UDP only as valid protocol values and actually has >>> icmpcode/icmptype parameters that are used for ICMP rules. For the >>> SecurityGroupRule class my thoughts were to make the protocol and from/to >>> ports required parameters; however, CloudStack support may throw this >> off. >>> Information on their request parameters can be found at >> http://goo.gl/Byxi4U >>> . >> >> Actually this will work fine, I just tested it and it seems to be a bug in >> the apidoc, ICMP is supported in the protocol field. >> But CloudStack will need to know the type of icmp packets allowed (type >> and code). >> >> FYI, the latest doc is at: >> >> http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/authorizeSecurityGroupIngress.html >> >>
