in the process
Fixes#7577
7577 discovered that sometimes setting tags at the end of the creation
model doesn't quite work for everyone. We now move that further up the
tree by calling the setTags func a second time.
The setTags func in the Update is not called immediately after creation
as we check for it not being a NewResource
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSecurityGroup_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSSecurityGroup_ -timeout 120m
=== RUN TestAccAWSSecurityGroup_importBasic
--- PASS: TestAccAWSSecurityGroup_importBasic (60.96s)
=== RUN TestAccAWSSecurityGroup_importSelf
--- PASS: TestAccAWSSecurityGroup_importSelf (72.72s)
=== RUN TestAccAWSSecurityGroup_basic
--- PASS: TestAccAWSSecurityGroup_basic (62.33s)
=== RUN TestAccAWSSecurityGroup_namePrefix
--- PASS: TestAccAWSSecurityGroup_namePrefix (22.12s)
=== RUN TestAccAWSSecurityGroup_self
--- PASS: TestAccAWSSecurityGroup_self (64.26s)
=== RUN TestAccAWSSecurityGroup_vpc
--- PASS: TestAccAWSSecurityGroup_vpc (58.35s)
=== RUN TestAccAWSSecurityGroup_vpcNegOneIngress
--- PASS: TestAccAWSSecurityGroup_vpcNegOneIngress (54.95s)
=== RUN TestAccAWSSecurityGroup_MultiIngress
--- PASS: TestAccAWSSecurityGroup_MultiIngress (64.81s)
=== RUN TestAccAWSSecurityGroup_Change
--- PASS: TestAccAWSSecurityGroup_Change (96.86s)
=== RUN TestAccAWSSecurityGroup_generatedName
--- PASS: TestAccAWSSecurityGroup_generatedName (60.75s)
=== RUN TestAccAWSSecurityGroup_DefaultEgress_VPC
--- PASS: TestAccAWSSecurityGroup_DefaultEgress_VPC (57.05s)
=== RUN TestAccAWSSecurityGroup_DefaultEgress_Classic
--- PASS: TestAccAWSSecurityGroup_DefaultEgress_Classic (20.94s)
=== RUN TestAccAWSSecurityGroup_drift
--- PASS: TestAccAWSSecurityGroup_drift (27.39s)
=== RUN TestAccAWSSecurityGroup_drift_complex
--- PASS: TestAccAWSSecurityGroup_drift_complex (64.62s)
=== RUN TestAccAWSSecurityGroup_tags
--- PASS: TestAccAWSSecurityGroup_tags (87.49s)
=== RUN TestAccAWSSecurityGroup_CIDRandGroups
--- PASS: TestAccAWSSecurityGroup_CIDRandGroups (71.62s)
=== RUN TestAccAWSSecurityGroup_ingressWithCidrAndSGs
--- PASS: TestAccAWSSecurityGroup_ingressWithCidrAndSGs (69.60s)
=== RUN TestAccAWSSecurityGroup_ingressWithCidrAndSGs_classic
--- PASS: TestAccAWSSecurityGroup_ingressWithCidrAndSGs_classic (25.47s)
=== RUN TestAccAWSSecurityGroup_egressWithPrefixList
--- PASS: TestAccAWSSecurityGroup_egressWithPrefixList (64.46s)
=== RUN TestAccAWSSecurityGroup_failWithDiffMismatch
--- PASS: TestAccAWSSecurityGroup_failWithDiffMismatch (60.21s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws
1166.983s
```
Change the `RetryFunc` from a plain `error` return type to a
specialized `RetryError` which must decide whether it is
retryable or not.
Add `RetryableError` / `NonRetryableError` factory functions that
callers are meant to use to build up these errors.
This makes it eminently clear whether or not a given error is
retryable from inside the client code.
Goal here is to _not_ change any behavior, simply reflect the
existing behavior with the new, clearer, API.
This landed in aws-sdk-go yesterday, breaking the AWS provider in many places:
3c259c9586
Here, with much sedding, grepping, and manual massaging, we attempt to
catch Terraform up to the new `awserr.Error` interface world.
* ctiwald/ct/fix-protocol-problem:
aws: Document the odd protocol = "-1" behavior in security groups.
aws: Fixup structure_test to handle new expandIPPerms behavior.
aws: Add security group acceptance tests for protocol -1 fixes.
aws: error on expndIPPerms(...) if our ports and protocol conflict.
Ingress and egress rules given a "-1" protocol don't have ports when
Read out of AWS. This results in hashing problems, as a local
config file might contain port declarations AWS can't ever return.
Rather than making ports optional fields, which carries with it a huge
headache trying to distinguish between zero-value attributes (e.g.
'to_port = 0') and attributes that are simply omitted, simply force the
user to opt-in when using the "-1" protocol. If they choose to use it,
they must now specify "0" for both to_port and from_port. Any other
configuration will error.
Radek Simko