resilien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
terraform/website/source/docs/providers/cloudstack/r/ipaddress.html.markdown

50 lines
1.5 KiB
Markdown
Raw Normal View History

First release of a provider for CloudStack Of course not all resources are covered by this first release, but there should be enough resources available to handle most common operations. Tests and docs are included.
2014-12-10 22:20:52 +01:00
---
layout: "cloudstack"
page_title: "CloudStack: cloudstack_ipaddress"
sidebar_current: "docs-cloudstack-resource-ipaddress"
description: |-
Acquires and associates a public IP.
---
# cloudstack\_ipaddress
Acquires and associates a public IP.
## Example Usage
```
resource "cloudstack_ipaddress" "default" {
Refactor the use of names vs IDs for parameters referencing other TF resources We have a curtesy function in place allowing you to specify both a `name` of `ID`. But in order for the graph to be build correctly when you recreate or taint stuff that other resources depend on, we need to reference the `ID` and *not* the `name`. So in order to enforce this and by that help people to not make this mistake unknowingly, I deprecated all the parameters this allies to and changed the logic, docs and tests accordingly.
2016-04-11 17:14:19 +02:00
network_id = "6eb22f91-7454-4107-89f4-36afcdf33021"
First release of a provider for CloudStack Of course not all resources are covered by this first release, but there should be enough resources available to handle most common operations. Tests and docs are included.
2014-12-10 22:20:52 +01:00
}
```
## Argument Reference
The following arguments are supported:
Refactor the use of names vs IDs for parameters referencing other TF resources We have a curtesy function in place allowing you to specify both a `name` of `ID`. But in order for the graph to be build correctly when you recreate or taint stuff that other resources depend on, we need to reference the `ID` and *not* the `name`. So in order to enforce this and by that help people to not make this mistake unknowingly, I deprecated all the parameters this allies to and changed the logic, docs and tests accordingly.
2016-04-11 17:14:19 +02:00
* `network_id` - (Optional) The ID of the network for which an IP address should
website: address spelling mistakes, casing and links
2015-01-03 19:31:53 +01:00
be acquired and associated. Changing this forces a new resource to be created.
First release of a provider for CloudStack Of course not all resources are covered by this first release, but there should be enough resources available to handle most common operations. Tests and docs are included.
2014-12-10 22:20:52 +01:00
Refactor the use of names vs IDs for parameters referencing other TF resources We have a curtesy function in place allowing you to specify both a `name` of `ID`. But in order for the graph to be build correctly when you recreate or taint stuff that other resources depend on, we need to reference the `ID` and *not* the `name`. So in order to enforce this and by that help people to not make this mistake unknowingly, I deprecated all the parameters this allies to and changed the logic, docs and tests accordingly.
2016-04-11 17:14:19 +02:00
* `network` - (Optional, Deprecated) The name or ID of the network for which an IP
addess should be acquired and associated. Changing this forces a new resource
to be created.
* `vpc_id` - (Optional) The ID of the VPC for which an IP address should be
acquired and associated. Changing this forces a new resource to be created.
* `vpc` - (Optional, Deprecated) The name or ID of the VPC for which an IP address
should be acquired and associated. Changing this forces a new resource to be
created.
First release of a provider for CloudStack Of course not all resources are covered by this first release, but there should be enough resources available to handle most common operations. Tests and docs are included.
2014-12-10 22:20:52 +01:00
Fix issue #3033 and update tweak several cloudstack resources - Added a retry loop for attaching disks as this something was tried to fast when the VM was still booting - Fix issue #3033 - Update docs for latest updates and done some minor refactoring (styling)
2015-08-21 16:59:35 +02:00
* `project` - (Optional) The name or ID of the project to deploy this
instance to. Changing this forces a new resource to be created.
Refactor the use of names vs IDs for parameters referencing other TF resources We have a curtesy function in place allowing you to specify both a `name` of `ID`. But in order for the graph to be build correctly when you recreate or taint stuff that other resources depend on, we need to reference the `ID` and *not* the `name`. So in order to enforce this and by that help people to not make this mistake unknowingly, I deprecated all the parameters this allies to and changed the logic, docs and tests accordingly.
2016-04-11 17:14:19 +02:00
*NOTE: Either `network_id` or `vpc_id` should have a value!*
First release of a provider for CloudStack Of course not all resources are covered by this first release, but there should be enough resources available to handle most common operations. Tests and docs are included.
2014-12-10 22:20:52 +01:00
## Attributes Reference
The following attributes are exported:
website: address spelling mistakes, casing and links
2015-01-03 19:31:53 +01:00
* `id` - The ID of the acquired and associated IP address.
Make the CloudStack provider more inline with the other provider It turns out all other providers use `ip_address` where the CloudStack provider uses `ipaddress`. To make this more consistent this PR deprecates `ipaddress` and adds `ip_address` where needed…
2016-04-04 22:13:27 +02:00
* `ip_address` - The IP address that was acquired and associated.