[occm] Lookup ports by SG and not tags#2355
Conversation
When creating an SG for an LB we tag the ports we attach the SG to in order to be able to find them easily later on when the SG will be getting deleted. We do that to simulate an API allowing us to filter ports by attached SGs, but turns out - such an API already exists in Neutron and Gophercloud v1.6.0 allows to use it. This commit makes sure that when deleting an SG we're discovering ports to remove it from by querying the Neutron filtering by SG. Moreover tagging the ports with the SGs is removed to as not being necessary anymore. I've left the code removing the SG tags from ports for backward compatibility.
| return fmt.Errorf("failed to remove tag %s to port %s: %v", sg, port.ID, res.Err) | ||
|
|
||
| // Remove the security group ID tag from the port. Please note we don't tag ports with SG IDs anymore, | ||
| // so this stays for backward compatibility. It's reasonable to delete it in the future. 404s are ignored. |
There was a problem hiding this comment.
What's the backward compatibility? In case the user rolls back an upgrade, perhaps?
There was a problem hiding this comment.
Uhm, well, it will be a problem. The old code won't tag the ports again and deletion of SGs created with new version of the code will fail with the old code.
What's your advice here? Leave the tagging intact? I was really tempted to remove it as it saves us a Neutron call per port, but I guess we can leave it there for one more release?
There was a problem hiding this comment.
I was thinking just leave the legacy tags there and ignore them, but this is cleaner.
| func disassociateSecurityGroupForLB(network *gophercloud.ServiceClient, sg string) error { | ||
| // Find all the ports that have the security group associated. | ||
| listOpts := neutronports.ListOpts{TagsAny: sg} | ||
| listOpts := neutronports.ListOpts{SecurityGroups: []string{sg}} |
|
/approve in case @mdbooth you still want to take another look or feel free to unhold |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jichenjc The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| return fmt.Errorf("failed to remove tag %s to port %s: %v", sg, port.ID, res.Err) | ||
|
|
||
| // Remove the security group ID tag from the port. Please note we don't tag ports with SG IDs anymore, | ||
| // so this stays for backward compatibility. It's reasonable to delete it in the future. 404s are ignored. |
There was a problem hiding this comment.
I was thinking just leave the legacy tags there and ignore them, but this is cleaner.
|
Alright, I'm assuming I can unhold this. /hold cancel |
* Update gophercloud to v1.6.0 * Lookup ports by SG and not tags When creating an SG for an LB we tag the ports we attach the SG to in order to be able to find them easily later on when the SG will be getting deleted. We do that to simulate an API allowing us to filter ports by attached SGs, but turns out - such an API already exists in Neutron and Gophercloud v1.6.0 allows to use it. This commit makes sure that when deleting an SG we're discovering ports to remove it from by querying the Neutron filtering by SG. Moreover tagging the ports with the SGs is removed to as not being necessary anymore. I've left the code removing the SG tags from ports for backward compatibility.
|
/cherry-pick release-1.28 |
|
@dulek: #2355 failed to apply on top of branch "release-1.28": DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
* Update gophercloud to v1.6.0 * Lookup ports by SG and not tags When creating an SG for an LB we tag the ports we attach the SG to in order to be able to find them easily later on when the SG will be getting deleted. We do that to simulate an API allowing us to filter ports by attached SGs, but turns out - such an API already exists in Neutron and Gophercloud v1.6.0 allows to use it. This commit makes sure that when deleting an SG we're discovering ports to remove it from by querying the Neutron filtering by SG. Moreover tagging the ports with the SGs is removed to as not being necessary anymore. I've left the code removing the SG tags from ports for backward compatibility.
* Update gophercloud to v1.6.0 * Lookup ports by SG and not tags When creating an SG for an LB we tag the ports we attach the SG to in order to be able to find them easily later on when the SG will be getting deleted. We do that to simulate an API allowing us to filter ports by attached SGs, but turns out - such an API already exists in Neutron and Gophercloud v1.6.0 allows to use it. This commit makes sure that when deleting an SG we're discovering ports to remove it from by querying the Neutron filtering by SG. Moreover tagging the ports with the SGs is removed to as not being necessary anymore. I've left the code removing the SG tags from ports for backward compatibility.
What this PR does / why we need it:
When creating an SG for an LB we tag the ports we attach the SG to in order to be able to find them easily later on when the SG will be getting deleted. We do that to simulate an API allowing us to filter ports by attached SGs, but turns out - such an API already exists in Neutron and Gophercloud v1.6.0 allows to use it.
This commit makes sure that when deleting an SG we're discovering ports to remove it from by querying the Neutron filtering by SG. Moreover tagging the ports with the SGs is removed to as not being necessary anymore.
I've left the code removing the SG tags from ports for backward compatibility.
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:
Release note: