Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the auto_accept option for VpcPeeringConnection #1161

Closed
wants to merge 6 commits into from

Conversation

julienba
Copy link
Contributor

@julienba julienba commented Mar 9, 2015

} else {
d.Set("accept_status", pc.Status.Code)
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we try re-writing this so that resourceAwsVpcPeeringRead is the only place we're calling d.Set("accept_status") (at least in this context).

As is, a cursory glance shows setting accept_status if auto_accept is false, simply b/c the other set is in another function.

Additionally, we ignore the error returned from resourceVpcPeeringConnectionAccept here.

I'm thinking something like this:

[...]
// in resourceAwsVpcPeeringRead
code := pc.Status.Code
if v, ok := d.GetOk("auto_accept"); ok {
    updatedCode, err := resourceVpcPeeringConnectionAccept(ec2conn, pc, d.Id()); 
    if err!=nil {
        // error handling
    }

  //    set to new Status.code,
    //  or other handling
    code = updatedCode
}

d.Set("accept_status", code)
// remainder of func
[...]

func resourceVpcPeeringConnectionAccept(conn *ec2.EC2, oldPc *ec2.VpcPeeringConnection, id string) (string, error) {
// [...]
// accepts string ID instead of resource 
// returns string code, error
}

Or something to that effect..

@catsby
Copy link
Contributor

catsby commented Mar 9, 2015

Looks good so far, pending some nit-pick and questions

@catsby catsby added the waiting-response An issue/pull request is waiting for a response from the community label Mar 9, 2015
@catsby
Copy link
Contributor

catsby commented Mar 10, 2015

Hey @julienba – thanks for the cleanups!
I recently converted the AWS VPC Peering resource over to aws-sdk-go, so master has been updated (see #1174).

Could you take a shot at rebasing this on master? If it doesn't go cleanly I can try and make a new PR based off of yours here and get it merged.

Thanks again!

Conflicts:
	builtin/providers/aws/resource_aws_vpc_peering_connection.go
@julienba
Copy link
Contributor Author

I merged it. But I'm not sure of what I'm doing (go noobie here) with aws.StringValue, is that some kind of pointer ?

@catsby
Copy link
Contributor

catsby commented Mar 12, 2015

Yeah, the aws.StringValue is a bit crazy to me too. It may go away, awslabs is refactoring the library.

The merge looks good, thanks!

After further review though, I have to ask why the block of code that calls resourceVpcPeeringConnectionAccept is done in resourceAwsVpcPeeringRead and not resourceAwsVpcPeeringUpdate. If I understand correctly, that func will be called on every Read operation. I think the Read operation potentially changing the remote state would not be good. Can you move that block to the Update func?

Assuming I understand correctly, the flow would then be:

create->update (auto connect if needed) -> read.

@julienba
Copy link
Contributor Author

You're right, it makes more sense that way.

I doing it for avoiding to read ec2.VPCPeeringConnection one more time as I need it for knowing the pending-acceptance status before eventually calling AcceptVPCPeeringConnection.

Should I duplicate the call of resourceAwsVpcPeeringConnectionStateRefreshFunc inside the Update or inside resourceVpcPeeringConnectionAccept ?

@catsby catsby removed the waiting-response An issue/pull request is waiting for a response from the community label Mar 12, 2015
@catsby
Copy link
Contributor

catsby commented Mar 16, 2015

I would make the change and move this idea to the *Update func.

In that function, I would use a resource.StateChangeConf struct and do polling for the target state, like we do in Create. The target for your case would be pending-acceptance.

As is, it looks like if your VPC peering connection isn't in that state on the first run, you never re-attempt resourceVpcPeeringConnectionAccept until the next time we Read, unless I'm missing something ...

@catsby
Copy link
Contributor

catsby commented Mar 16, 2015

Looking into the code more, I noticed that, if without hitting an error, the refresh func will always return a state of ready (the string) instead of the actual state it found, which I think is a bug.

The AWS docs aren't terribly clear (from what I saw) as the the actual valid states, so I'm assuming the target state should really be our pending-acceptance, right?

@catsby catsby added the waiting-response An issue/pull request is waiting for a response from the community label Mar 16, 2015
@julienba
Copy link
Contributor Author

Yes it's pending-acceptance

Conflicts:
	builtin/providers/aws/resource_aws_vpc_peering_connection.go
@julienba
Copy link
Contributor Author

It's just me or the master is currently broken ?
I've this error:
Error creating VPC: Authorization header or parameters are not formatted correctly.

aws-sdk-go don't use credential in .aws folder anymore

@radeksimko
Copy link
Member

aws-sdk-go don't use credential in .aws folder anymore

Keep watching #1049

@julienba
Copy link
Contributor Author

great !

@catsby
Copy link
Contributor

catsby commented May 1, 2015

Hello – sorry for the late catch-up here. Terraform and it's current aws-sdk-go library should pick up an credentials in ~/.aws now. I hope that helps 😄

@mitchellh
Copy link
Contributor

LGTM just needs to be squashed

@mitchellh
Copy link
Contributor

or not squashed, but rebased

@catsby
Copy link
Contributor

catsby commented May 5, 2015

Did the rebasing #1809, going with that one. Thanks @julienba !

@catsby catsby closed this May 5, 2015
@ghost
Copy link

ghost commented May 3, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators May 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement provider/aws waiting-response An issue/pull request is waiting for a response from the community
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants