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

44 lines
1.1 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_nic"
sidebar_current: "docs-cloudstack-resource-nic"
description: |-
Creates an additional NIC to add a VM to the specified network.
---
# cloudstack\_nic
Creates an additional NIC to add a VM to the specified network.
## Example Usage
Basic usage:
```
resource "cloudstack_nic" "test" {
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"
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 = "192.168.1.1"
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
virtual_machine_id = "f8141e2f-4e7e-4c63-9362-986c908b7ea7"
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` - (Required) The ID of the network to plug the NIC into. Changing
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
this forces a new resource to be created.
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` - (Optional) The IP address to assign to the NIC. Changing this
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
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
* `virtual_machine_id` - (Required) The ID of the virtual machine to which to
attach the NIC. Changing this forces a new resource to be created.
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
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:
* `id` - The ID of the NIC.
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 assigned IP address.