Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
provider/gce: Don't base the name of firewall rules on hash of CIDRs #7246
Conversation
|
!!chittychitty!! |
|
Does this lead to us not being able to lookup a known firewall rule? Is
there a way we can have a rule that isn't 'content-based-addressing' ?
John
=:->
…
|
|
@jameinel: yeah, it does cause that problem, @wallyworld pointed it out to me in IRC. Since we can't update the name of the firewall rules it seems like the options are:
Option 1 can't be done atomically, and cleaning up the mess if the create happened but the delete didn't seems like it would be nasty. So I'm in the middle of doing 2 at the moment. Since the names will be unpredictable we need to hang on to them when we get the existing rules from GCE so we can send them back with updates/deletes. The old version of the code wasn't doing that - names were thrown away when the (Sorry, I should have marked this as a WIP - I'm still fixing up tests.) |
babbageclunk
changed the title from
provider/gce: Don't change the name of firewall when updating
to
WIP provider/gce: Don't change the name of firewall when updating
Apr 20, 2017
|
!!chittychitty!! |
babbageclunk
changed the title from
WIP provider/gce: Don't change the name of firewall when updating
to
provider/gce: Don't base the name of firewall rules on hash of CIDRs
Apr 21, 2017
babbageclunk
added some commits
Apr 18, 2017
wallyworld
approved these changes
Apr 24, 2017
It seems to be we're missing a test - the existing connSuite tests have been updated to reflect the new naming algorithm, but a test to check the update bug which necessitated this PR I think is needed
| + | ||
| +// FirewallNamer generates a unique name for a firewall given the firewall, a | ||
| +// prefix and a set of current firewall rule names. | ||
| +type FirewallNamer func(*firewall, string, set.Strings) (string, error) |
wallyworld
Apr 24, 2017
Owner
Best to name the function params to make parsing the description easier.
| - } | ||
| +// RandomSuffixNamer tries to find a unique name for the firewall by | ||
| +// appending a random suffix. | ||
| +func RandomSuffixNamer(fw *firewall, prefix string, names set.Strings) (string, error) { |
|
$$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Tests failed |
|
These are spurious failures - one's in a new VSphere test that Andrew's looking at, the other is one I've seen before. $$merge$$ |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Tests failed |
|
grr |
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
babbageclunk commentedApr 18, 2017
•
Edited 1 time
-
babbageclunk
Apr 18, 2017
Description of change
Found when testing #7234 - the updated addresses would be logged for updating the firewall, but the update wouldn't happen. The error on updating was being swallowed somewhere so it wasn't clear what was happening from the logs. (I'll fix that in a separate PR when I track it down.)
We were generating the name of the firewall using a hash of the new rules, and trying to update the firewall to have the new name. GCE will prevent a mismatch between the URL and the name with this
error:
Since we can't update the name of the firewall rules it seems like the options are:
Option 1 can't be done atomically, and cleaning up the mess if the create happened but the delete didn't seems like it would be nasty. So this change implements option 2.
Since the names will be unpredictable we need to hang on to them when we get the existing rules from GCE so we can send them back with updates/deletes. The old version of the code wasn't doing that - names were thrown away when the compute.Firewall is converted into []network.IngressRule because it could regenerate the name from the CIDRs.
QA steps