I think the best thing we can do for the extension is to focus on jclouds managed resources and ignore the rest. This means that jclouds will know how to map from firewall rules to SecurityGroups and back, and be able to figure out a security group is applied on a node.
This will allow users to continue using jclouds as a cloud abstraction and not care about the underlying implementation. This is also why it's fine to ignore the firewall rules that don't follow the convention (i.e. those created outside of jclouds) - users are interested in SecurityGroups and not GCE firewall rules for which there's the raw API. The only (virtual) SecurityGroups existing in the cloud are those created by jclouds. Svet. > On 15.06.2017 г., at 11:18, Ignasi Barrera <n...@apache.org> wrote: > > Thanks for starting this discussion Svet! > > It would be great to come up with a solution we are happy with. > > The main issue I see here is that the primary entity of the extension, > the SecurityGroup, does not have a mapping in GCE (which was one of > the reasons we decided to remove the old implementation). > > I am OK applying conventions to implement the extension somehow, but > conventions are tricky when it comes to deal with existing stuff in > the provider. With this proposal, what are your plans to implement the > "listSecurityGroups()" and "listSecurityGroupsInLocation(Location > location)" methods? There is also a method to list the security groups > from a node. Given that the ComputeService is able to "listNodes" that > weren't created by jclouds, in case of a returned Node that already > has firewall rules assigned but that don't fit in our naming > conventions, how would the "listSecurityGroupsForNode(String id)" > behave? > > I. > > On 15 June 2017 at 09:03, Svetoslav Neykov > <svetoslav.ney...@cloudsoftcorp.com> wrote: >> I'd like to try implement the SecurityGroupExtension interface for GCE. >> Looking at the documentation it seems that the combination of firewall rules >> and node tags is flexible enough to allow us implement the functionality. >> It's been tried before but the implementation's been removed (see [1]). It's >> main drawback was that for each security group the code creates a new >> network. >> Currently the biggest mismatch between the jclouds abstraction and the GCE >> functionality is that firewall rules must be attached to a network. >> Here's my suggested approach: >> IpPermission roughly corresponds to a firewall rule >> SecurityGroup is just a collection of firewall rules (there's no cloud >> resource that corresponds to it). The firewall rules of a security group >> share the same prefix - jclouds-sg-<sg name>-<permission suffix>. They all >> belong to the same network. >> They key bit: createSecurityGroup accepts a Location with a scope of >> Network, returning a custom implementation of SecurityGroup which keeps a >> reference to the network, so all IpPermission objects added subsequently >> will be on it. >> While the suggested approach fits into the SecurityGroupExtension interface >> it's different enough from the other implementations that it might not be >> worth the trouble of implementing and supporting (even be harmful as users >> might be surprised by the different behaviour). >> Would be interested in hearing other opinions on the approach. I've created >> a Jira to track the effort at [2]. >> >> Svet. >> >> >> [1] >> https://github.com/jclouds/jclouds/commit/2ba48dc9f66416b5d8515bd6a07b27a213d89a7c >> >> <https://github.com/jclouds/jclouds/commit/2ba48dc9f66416b5d8515bd6a07b27a213d89a7c> >> [2] https://issues.apache.org/jira/browse/JCLOUDS-1309 >> <https://issues.apache.org/jira/browse/JCLOUDS-1309> >>
