-
Notifications
You must be signed in to change notification settings - Fork 113
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 support for Consul Peering #309
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting this PR up. There have been a few changes since the alpha which will necessitate some changes but overall, almost everythingin the PR looks correct to me.
Read: func(*schema.ResourceData, interface{}) error { | ||
return nil | ||
}, | ||
Delete: func(*schema.ResourceData, interface{}) error { | ||
return nil | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, so peering token create will behind the scenes create a peering that can be read or deleted. The read and delete functions should be able to reuse what you created for the consul_peering resource. Without support for deletions, you could not use the tf provider to manage peerings without leaking the accepting side of the peering relationship.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mkeeler, I'm not sure what else could do here, there's support for deleting a peering connection at https://github.com/remilapeyre/terraform-provider-consul/blob/peering/consul/resource_consul_peering.go#L163-L173 but the Consul API does not provide a way to invalid a Peering token that has not yet been used to established a connection.
Support for doing this with the Consul API would be needed if we want to implement a meaningful Delete() for this resource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does work but the peering APIs are a bit asymmetrical:
➜ curl -X POST localhost:8500/v1/peering/token -d '{"PeerName": "foo"}'
{
"PeeringToken": "eyJDQSI6bnVsbCwiU2VydmVyQWRkcmVzc2VzIjpbIjEyNy4wLjAuMTo4NTAyIl0sIlNlcnZlck5hbWUiOiJzZXJ2ZXIuZGMxLmNvbnN1bCIsIlBlZXJJRCI6IjRmZmJkMzljLWZkYzYtOThkOC1kMWE3LWU3MjM3ZTEyMjllOSIsIkVzdGFibGlzaG1lbnRTZWNyZXQiOiJmYTE0M2Y1MS1kNDU1LThiYWQtNWM5Yi0yMDFhZmY2NTk4YzQifQ=="
}
~
➜ curl localhost:8500/v1/peerings
[
{
"ID": "4ffbd39c-fdc6-98d8-d1a7-e7237e1229e9",
"Name": "foo",
"Partition": "default",
"State": "PENDING",
"ImportedServiceCount": 0,
"ExportedServiceCount": 0,
"CreateIndex": 18,
"ModifyIndex": 18
}
]
~
➜ curl -X DELETE localhost:8500/v1/peering/foo
~
➜ curl localhost:8500/v1/peerings
[]
Basically issuing a request to either POST /v1/peering/token
or POST /v1/peering/establish
will create a peering which can be deleted with a DELETE /v1/peering/<peer name>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly you can still read an individual peering that has a token generated for it but the stream is not yet established:
➜ curl localhost:8500/v1/peering/foo
{
"ID": "947b29ca-8dcf-1d61-1da8-0defeda6e0f0",
"Name": "foo",
"Partition": "default",
"State": "PENDING",
"ImportedServiceCount": 0,
"ExportedServiceCount": 0,
"CreateIndex": 27,
"ModifyIndex": 27
}
The PENDING state here indicates that the stream is not established.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mkeeler, all should be good now.
No description provided.