allowing for http api to be used for fleet provider

[brendangibat]

I need update docs, just allows for creating an api client with an http endpoint without going through ssh.

[bitglue]

This doesn't seem to be testing "when the address is an empty string, we get a nullAPI", though maybe it doesn't matter anymore. It used to be that if the tunnel_address was something like ${aws_instance.coreos.public_ip}, then when terraform would expand that variable in the planning stage, before that instance existed, it would expand it to an empty string. When that happened, all we needed to do was to not fail, and then when Terraform would get to the apply stage it wouldn't initialize the fleet provider until after the instance was actually created, and by then we'd have the real IP address and could work normally.

However, this doesn't seem to work in more recent versions of Terraform, for reasons I haven't yet fully investigated. hashicorp/terraform#2430 has a bit more context.

Until that's sorted out, perhaps it's best to retain the old behavior.

[brendangibat]

One of the comments on that linked thread:
"""
The workaround for this problem is to explicitly split the problem into two steps: make one Terraform config that creates the EC2 instance and produces the instance IP address as an output, publish the state from that configuration somewhere, and then use the terraform_remote_state resource to reference that from a separate downstream config that sets up the Docker resources.
"""
So that's what I'm doing currently, but I'll add back in that expected functionality in the case of an empty string. I didn't understand why it was operating that way but it makes sense. I'll keep up on that ticket as well.

[bitglue]

driver = "api" means to use the fleet HTTP API, not frobbing etcd directly, right? If so, it's pretty unlikely the endpoint would be on port 4001 in this case.

[brendangibat]

It is, that's a bad example I didn't mean to push