Where AWS doesn’t have an explicit ID and our API would be rubbish without one I have in the past fabricated one. Records in the Route53 API spring to mind. So for AWS i would consider setting the id property to “:”.join(self.source, self.proto, self.from) or similar.
I think this is kind of thing is essential if you are building a web app and you need to refer to the same SecurityGroup between HTTP requests (you can’t just pass the same SecurityGroup object around). On 12 Jan 2014, at 16:38, Chris DeRamus <[email protected]> wrote: > The gist has been updated at https://gist.github.com/cderamus/8182092 and > is ready for review. If desired, we could add a direction parameter to the > authorize/revoke methods to specify a direction (ingress vs. egress). The > reason I kept them separate was mainly just because I thought calling out > the direction in the method name made it more obvious what it was doing. > > @Tomaz. You asked if revoking the rule just required the ID. For OpenStack > that is correct, but AWS revokes the rule based on the source, protocol and > to/from port values. They don't use IDs at all. > > > > > On Mon, Jan 6, 2014 at 8:08 AM, sebgoa <[email protected]> wrote: > >> >> 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 >>>> >>>> >> >>
