Ah, that's a good point John and I agree entirely. I've updated the gist and will keep that in mind moving forward.
On Sun, Jan 12, 2014 at 11:49 AM, John Carr <[email protected]> wrote: > 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/8182092and > > 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 > >>>> > >>>> > >> > >> > >
