Closed wninobla closed 8 years ago
Ah, I was wondering if anyone would ask about this :)
The way it works currently is that creating a NAT rule (which gets the first available public IP address) will auto-allocate a public IP block if there are no free IP addresses available at deploy time.
I avoided exposing IP blocks directly because, at the time you're writing the Terraform configuration, you don't know how many addresses you'll get when you allocate a block. That sort of non-deterministic behaviour doesn't mix all that well with Terraform. I could implement a ddcloud_public_ip_block
resource but then how would you index the returned IP addresses for use in the rest of your configuration? It kinda breaks the use of Terraform's count
behaviour.
OK, reading it in that way it makes sense. I think it is however a fundamental design choice in how terraform will be used in the future. If for instance we add new IP's based on the current methodology, it works out OK. But, if we're using this more as a configuration tool where we "reassign a NAT address" to something else, we may be in or out of scope in how Terraform is currently used to build out stuff. Things like Ansible where we can actively change individual items may make more sense here.
Again, just raising the concerns from what I see. Let me know - thanks!
Hmm, let me have a think about this and get back to you...
On 27 Sep. 2016, at 2:36 am, wninobla notifications@github.com wrote:
OK, reading it in that way it makes sense. I think it is however a fundamental design choice in how terraform will be used in the future. If for instance we add new IP's based on the current methodology, it works out OK. But, if we're using this more as a configuration tool where we "reassign a NAT address" to something else, we may be in or out of scope in how Terraform is currently used to build out stuff. Things like Ansible where we can actively change individual items may make more sense here.
Again, just raising the concerns from what I see. Let me know - thanks!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Ok. Sorry but for now I think this one may not be practical to implement.
If you run into a specific use case that is being blocked by it, though, let me know and I'll reopen it.
OK no problem - thanks!
Regards,
William Ninobla Sr. Solutions Architect Cloud Business Unit Dimension Data
From: Adam Friedman notifications@github.com Sent: Monday, October 31, 2016 2:56 PM To: DimensionDataResearch/dd-cloud-compute-terraform Cc: William Ninobla (ITaaS); Author Subject: Re: [DimensionDataResearch/dd-cloud-compute-terraform] Request for Enhancement - Reference to add Public IPv4 blocks (#21)
Ok. Sorry but for now I think this one may not be practical to implement.
If you run into a specific use case that is being blocked by it, though, let me know and I'll reopen it.
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/DimensionDataResearch/dd-cloud-compute-terraform/issues/21#issuecomment-257432902, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQe9vy5dj-5KxbvTAXYSdBbsC4TqFqOUks5q5mQmgaJpZM4KE1Lr.
itevomcid
Hi,
Looking to add/remove separately IPv4 public addresses. We have customers like Sonata who add multiple IP's based on how their application needs dictate. Is there a method not documented that allows this?