Disclaimer: Terraform Provider ZEDEDA CLOUD is in the early customer testing phase and is not yet a fully supported feature. Please contact the ZEDEDA Customer Success team if you would like to try out the feature.
1. Introduction
Terraform Provider ZEDEDA CLOUD module allows users to use Terraform to manage their ZEDEDA CLOUD configuration. Terraform Provider ZEDEDA CLOUD can be considered as yet another user agent, like ZEDEDA UI and CLI, written in Golang.
Use the ZEDEDA CLOUD provider to interact with the many resources supported by ZEDEDA. You must configure the provider with the proper credentials before you can use it.
In the following diagram, you can see that Terraform core sends an execute action command to the ZEDEDA CLOUD provider, and ZEDEDA CLOUD sends the response.
For more information on Terraform, see Introduction to Terraform. The rest of the document assumes that the user is familiar with Terraform. If not, see Installing Terraform and Initializing Terraform Working Directories.

1.1. Understanding ZEDEDA CLOUD Objects and their Relationships:
The following diagram illustrates the dependencies between various ZEDEDA CLOUD objects. For example, as shown in the diagram below, 'Edge App Instances' depend on 'Volume Instances', 'Edge App', 'Edge Node', and 'Network Instance'.

1.2. Encoding Object Dependencies in Terraform Configuration Files
Users of Terraform Provider ZEDEDA CLOUD must understand the dependencies for each object. These dependencies must be specified in the Terraform configuration files (.tf files) for resources. These can be done as an explicit dependency (using the 'depends_on' block) or implicit dependency (using references to other data sources and resources). Wherever possible, using implicit dependencies is recommended. Specifying the dependencies for each resource correctly guarantees that Terraform configures the resources in the appropriate order.
See Create Resource Dependencies for more information on Terraform dependency support.
Example 1: Edge Node Dependencies
Edge Node (resource zedcloud_edgenode) depends on the following:
- Network (resource zedcloud_network)
The following is an example of specifying such dependencies (implicit dependency):
resource "zedcloud_network" "Sample-Network1" {
name = "sample-network1"
<snip>
}
resource "zedcloud_network" "Sample-Network2" {
name = "sample-network2"
<snip>
}
resource "zedcloud_edgenode" "Sample-Device" {
<snip>
interface {
intfname = "eth0"
netname = zedcloud_network.Sample-Network1.name
<snip>
}
interface {
intfname = "eth1"
// This creates implicit dependency on zedcloud_network.Sample-Network2
netname = zedcloud_network.Sample-Network2.name
<snip>
}
}
Example 2: Edge Application Dependencies
Edge application depends on the following:
- Image (zedcloud_image)
Since the required image is specified in the manifest file, Terraform doesn't recognize the implicit dependency. Hence an explicit dependency needs to be added. The following is an example of specifying such explicit dependencies:
resource "zedcloud_image" "Sample-Image1" {
name = "sample-image1"
<snip>
}
resource "zedcloud_edgeapp" "Sample-EdgeApp" {
<snip>
// Explicit dependency on Sample-Image1
depends_on = [
zedcloud_Image.Sample-Image1
]
}
Example 3: Edge Application Instance Dependencies
Edge application instances depend on:
- Edge Node (zedcloud_edgenode)
- Network Instance (zedcloud_network_instance)
- Edge App (zedcloud_edgeapp)
The following is an example of adding these as implicit dependencies:
resource "zedcloud_edgenode" "Sample-EdgeNode1" {
name = "sample-edgenode1"
<snip>
}
resource "zedcloud_network_instance" "Sample-NetInst1" {
name = "sample-netinst1"
<snip>
}
resource "zedcloud_edgeapp" "Sample-EdgeApp1" {
name = "sample-edgeapp1"
<snip>
}
resource "zedcloud_edgeapp_instance" "Sample-EdgeAppInst1" {
name = "sample-edgeapp-inst1"
// This adds an implicit dependency on Sample-EdgeApp1
app_id = zedcloud_edgeapp.Sample-EdgeApp1.id
// This adds an implicit dependency on Sample-EdgeNode1
device_id = zedcloud_edgenode.Sample-EdgeNode1.id
interface {
intfname = "eth0"
// this adds implicit dependency on Sample-NetInst1
netinstname = zedcloud_network_instance.Sample-NetInst1.name
}
<snip>
}
1.3. Schema Documentation
2. Recommended Usage of Terraform with ZEDEDA CLOUD
- Users must use either Terraform or ZEDEDA CLOUD user agents (UI/CLI) to manage the configuration of ZEDEDA CLOUD objects, but not both.
- Using both to change the configuration of objects could result in the corruption of objects.
- Terraform does not offer any monitoring capability. It is a configuration management tool.
- Users will have to use CLI or UI to monitor the Edge Infrastructure and see various states and reports.
- To migrate objects already created in ZEDEDA CLOUD to Terraform, see section 4.
- After an object has been imported into Terraform, Terraform must be used exclusively to manage any further configuration of the object.
3. Authenticate ZEDEDA CLOUD Provider
The following two authentication options are supported:
- Token-based (recommended)
- Click here for details on generating the token from ZEDEDA CLOUD
- Username/Password
Token and username/password are specified in the provider section of the configuration file. The Token is the preferred authentication method. Either Token or username/password must be specified, but not both.
Generally, secrets like API tokens or usernames/passwords are not specified directly in plain text in the .tf file. One way to specify such secrets in terraform is to use sensitive variables. Variables can be passed to terraform commands (plan/apply) using environment variables (TFVAR). If environment variables are not set, terraform plan / terraform applied will interactively ask for the values to be provided.
3.1. Token-Based Authentication
variable "zedcloud_token" {
description = "ZEDCloud API token. Set environment variable TF_VAR_zedcloud_token"
sensitive = true
type = string
}
provider "zedcloud" {
zedcloud_url = "https://zedcontrol.zededa.net"
zedcloud_token = var.zedcloud_token
}
3.2. Username/Password-Based Authentication
variable "username" {
description = "ZEDCloud username. Set environment variable TF_VAR_username"
sensitive = true
type = string
}
variable "password" {
description = "ZEDCloud password. Set environment variable TF_VAR_password"
sensitive = true
type = string
}
provider "zedcloud" {
zedcloud_url = "https://zedcontrol.zededa.net/"
username = var.username
password = var.password
}
4. Import Terraform Configuration for Resources
The terraform import command can be used to import the state of existing ZEDEDA CLOUD objects into Terraform. Once imported, Terraform completely manages the resources for any further changes to the configuration. All ZEDEDA CLOUD objects supported by Terraform Provider ZEDEDA CLOUD also support terraform import command.
To import an existing ZEDEDA CLOUD object into Terraform state:
- Identify the ID of the object using ZEDEDA UI or CLI
- Add a corresponding resource block for the object in the Terraform configuration (.tf file)
- use the command 'terraform import <resource_type>.<resource-name> <id>'.
For example: terraform import zedcloud_edgenode.Sample-Device 99999999-bbbb-aaaa-1111-bbbbbbbbbbbb
Here is an example of the import command:
Macbook tfdir:$ terraform import zedcloud_edgenode.Sample-Device 3ab53292-ad51-4807-9ae7-d2882cc3c600
zedcloud_edgenode.Sample-Device: Importing from ID "3ab53292-ad51-4807-9ae7-d2882cc3c600"...
zedcloud_edgenode.Sample-Device: Import prepared!
Prepared zedcloud_edgenode for import
zedcloud_edgenode.Sample-Device: Refreshing state... [id=3ab53292-ad51-4807-9ae7-d2882cc3c600]
Import successful!
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.
Macbook tfdir:$
5. Handling Secrets
Users are advised to use sensitive variables to pass secrets in the terraform configuration instead of storing them as plain text in the terraform configuration files. These are recommended for secrets like token, username, and password in the provider section, as well as other sections like Wifi Passwords, App Instance Custom configuration, etc.
The following example shows the username and password variables to be used in the provider block:
variable "username" {
description = "ZEDCloud username"
sensitive = true
type = string
}
variable "password" {
description = "ZEDCloud password"
sensitive = true
type = string
}
provider "zedcloud" {
zedcloud_url = "https://zedcontrol.zededa.net"
username = var.username
password = var.password
}
To pass the secrets, the user needs to set environment variables of type TF_VAR_<variable name>. Following is an example showing the same:
export TF_VAR_username=foo
export TF_VAR_password=foobar
The 'terraform plan' and 'terraform apply' pick up the values for the variables from the environment variables.
6. Example Usage Configurations
The following ZEDEDA CLOUD objects are supported as both resources and data sources:
- Networks
- Images
- Edge Node
- Volume Instances
- Edge Application
- Network Instances
- Edge Application Instance
The following ZEDEDA CLOUD objects are supported only as data sources:
- Datastore
Note: Datasources support only name as the key.
Note: Edge Node creation must be done through ZEDEDA CLOUD, but can be subsequently managed using Terraform by importing state into Terraform. See the Edge Node section for more details.
The rest of the ZEDEDA CLOUD objects, like projects, device models, users, etc, are not currently supported by Terraform. They have to be managed either through UI or CLI. Support for the rest of the ZEDEDA CLOUD objects will be considered for future releases.
Let's see in the following sections, how Terraform manages configuration for each of the above objects. The chronology of these sub-chapters is based on a recommended sequence of operations.
6.1. Networks
Network objects are used to configure network connectivity to the edge nodes. Click here to learn further details.
The following are some attributes of resource typezedcloud_network:
- enterprise_default.
- Set this to true to make this Network the default network for the project.
- project_id
- Specify the project ID for the network. If the Project ID is not specified, the network object would be created in the default project for the enterprise.
- kind
- Specify if this is an IPV4 or IPV6 Network object.
- ip
- This block configures the IP address and related aspects of the interface.
-
- DHCP
- Configure the interface to use STATIC IP address or use DHCP Client
- DHCP
6.1.1. Configure IPv4 DHCP Client Network Object
The following is a simple Network that configures the edge node interface to be a DHCP Client.
resource "zedcloud_network" "TF-sample-network-ip-dhcp-client" {
name = "defaultIPv4-net"
title = "default-network"
description = "Simple IPv4 DHCP Client"
enterprise_default = false
kind = "NETWORK_KIND_V4"
ip {
dhcp = "NETWORK_DHCP_TYPE_CLIENT"
}
// Project ID. For Default project, set to empty string
project_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
}
6.1.2. Configure Network with Static IPv4 Address
The following is an example of configuring a Network object that would assign a static address to the interface configured with the network.
The following fields are the important ones to note:
- dhcp = "NETWORK_DHCP_TYPE_STATIC"
- This specifies that the Network should assign a static IP address
- dhcp_range
- This block specified the range of IP addresses to be used for Static assignment. ZEDEDA CLOUD picks an IP address from this range to assign to each interface configured
- subnet
- A subnet of the IP address
- dns
- Specify a list of DNS servers to be used by the edge node
- domain
- Specify the Domain to be used
- gateway
-
- Gateway IP address
resource "zedcloud_network" "TF-sample-network-ip-sample" {
name = "defaultIPv4-net
title = "default-network
description = "Simple IPv4 DHCP Client"
kind = "NETWORK_KIND_V4"
ip {
// set dhcp to STATIC for Static IPv4 address
dhcp = "NETWORK_DHCP_TYPE_STATIC"
dhcp_range {
start = "172.25.24.1"
end = "172.25.24.25"
}
dns = [
"172.25.24.254"
]
domain = "testtf.com"
gateway = "172.25.24.254"
ntp = "216.239.35.0"
subnet = "172.25.24.0/22"
}
project_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
}
6.2. Images
zedcloud_image represents an image in ZEDEDA CLOUD. The image can be an EVE-OS image or an application image. Images are supported as both resources and data sources. Image objects can be used to configure images but not upload the images to ZEDEDA CLOUD.
EVE images used by the Edge Nodes are recommended to be configured as a data source. The data source can then be referenced from the edge node eve_image_version attribute.
Application Images are recommended to be configured as resources. An Application image refers to a DataStore, so ZEDEDA CLOUD must have appropriate data stores already configured.
The following are some notable attributes in the zedcloud_image resource:
- image_arch
- The following image architectures are supported:
- AMD64
- ARM64
- The following image architectures are supported:
- image_format
- The following image formats are supported:
- "RAW"
- "QCOW"
- "QCOW2"
- "VHD"
- "VMDK",
- "OVA"
- "VHDX"
- "CONTAINER"
- The following image formats are supported:
- image_rel_url
-
URL of the image relative to DataStore base URL.
-
- image_type
- The following image types are supported
- IMAGE_TYPE_EVE
- IMAGE_TYPE_APPLICATION
- The following image types are supported
The following is an example of images as a data source and resource.
data "zedcloud_image" "EVE-OS-6-8-2-kvm-amd64" {
name = "6.8.2-kvm-amd64"
}
resource "zedcloud_image" "TF-Sample-Application-Image" {
name = "TF-Sample-Application-Image"
datastore_id = "99999999-bbbb-aaaa-1111-bbbbbbbbbbbb"
description = "Sample Application Image"
image_arch = "AMD64"
image_format = "QCOW2"
image_rel_url = "tf-sample-app-image"
image_sha_256 = "9449F528B6EFF5EE953E61FA93DD6E3E7376DBAA4954B72B34212695E0FE7715"
image_size_bytes = "2405892096"
image_type = "IMAGE_TYPE_APPLICATION"
title = "TF-Sample-Application-Image"
}
6.3. Edge Node
The following diagram illustrates the interaction between Edge Node-related objects only.

6.3.1. Importing Edge Nodes into Terraform State
The following is the command to import an edge node into Terraform state:
terraform import zedcloud_edgenode.<resource-name> <id of edge-node>
6.3.2 Creating Edge Node using Terraform
The following are some notable fields used for onboarding the Edge Node:
- model_id – id of the model object for the Edge Node.
- project_id – id of the project to which the Edge Node belongs.
- serialno – serial number of the Edge Node as reported by EVE-OS.
- eve_image_version – version of EVE-OS image to be used by the Edge Node. This must be specified when configuring an EdgeNode using Terraform.
The following is an example of creating an Edge Node using Terraform:
resource "zedcloud_edgenode" "Sample-Device" {
adminstate = "ADMIN_STATE_ACTIVE"
asset_id = "sample asset id"
config_items = {
// Add Desired Config Items here
"debug.disable.dhcp.all-ones.netmask" = "true"
"network.fallback.any.eth" = "disabled"
"timer.config.interval" = "100"
"timer.reboot.no.network" = "31536000"
}
cpu = 4
description = "Sample device Description"
eve_image_version = "6.8.2-kvm-amd64"
id = "aaa-ad51-4807-9ae7-d2882cc3c600"
memory = 8192
model_id = "99999999-bbbb-aaaa-1111-bbbbbbbbbbbb"
name = "sample edge node"
project_id = "99999999-bbbb-aaaa-1111-aaaaaaaaaaaa"
serialno = "Test Serial Num"
storage = 256
tags = {
"tag1" = "tag-value1"
"tag2" = "tag-value2"
}
thread = 2
title = "Sample Device Title Test"
utype = "AMD64"
dev_location {
city = "San Jose"
country = "USA"
hostname = "sample-device"
org = "Zededa Engineering"
postal = "95116"
region = "Alameda County"
underlay_ip = "10.1.1.1"
}
interface {
cost = 0
intf_usage = "ADAPTER_USAGE_MANAGEMENT"
intfname = "eth0"
tags = {}
}
interface {
cost = 0
intf_usage = "ADAPTER_USAGE_UNSPECIFIED"
intfname = "eth1"
tags = {}
}
}
6.3.3. Configuring EVE-OS Runtime Configuration Properties
ZEDEDA CLOUD supports the following EVE-OS runtime configuration properties.
- timer.config.interval
- Configure how frequently Edge Node gets config
- Value: Integer in seconds ( for example '100')
- network.fallback.any.eth
- if no connectivity, try any Ethernet, WiFi, or LTE
- Value: 'enabled' or 'disabled'
- debug.disable.dhcp.all-ones.netmask (true/false)
- Disables the network mask /32 in DHCP configuration in Network Instances.
- Value: Boolean ('true'/'false')
- timer.reboot.no.network
- Reboot the Edge Node if there is no connectivity to ZEDEDA CLOUD for the specified time.
- Value: Integer in seconds (for example '100')
- timer.use.config.checkpoint
- Use checkpointed config if the device has no cloud connectivity after rebooting after the specified time.
- Value: Integer in seconds (for example '100')
The config_itemsblock must be used to configure EVE-OS runtime configuration properties. The following is an example of using config_items.
resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
config_items = {
"timer.config.interval" = "100"
"debug.disable.dhcp.all-ones.netmask" = "true"
// Disable the network-fallback option
"network.fallback.any.eth" = "disabled"
// Set the reboot-on-no-network timer to 1 year
"timer.reboot.no.network" = "31536000"
// Set the config checkpoint timer to 1 year
"timer.use.config.checkpoint" = "31536000"
}
<snip>
}
6.3.4. Update EVE-OS Image
To update the EVE-OS image on the Edge Node, set the attribute eve_image_versionto the appropriate image version. The recommended workflow is as follows:
- Verify if the required EVE-OS image is in the ZEDEDA CLOUD. Either use CLI or UI to verify the same.
- Add the Image as a data source.
- This guarantees that the image exists in ZEDEDA CLOUD before Terraform attempts to update the Edge Node configuration.
- Set the eve_image_versionattribute in the edge node resource block to the target EVE-OS version using the image data source from (2) above.
- Using a reference to the image data source adds an implicit dependency for the Edge node on the Image object.
- This ensures Terraform first verifies the image state before updating the Edge Node Configuration
- The next terraform application will update the edge note configuration with the new eve image version, along with any other changes in the configuration.
data "zedcloud_image" "6-8-2-kvm-amd64" {
name = "6.8.2-kvm-amd64"
}
resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
eve_image_version = data.zedcloud_image.6-8-2-kvm-amd64
<snip>
}
6.3.5. Configure Edge Node Interfaces
Use
interface
blocks to configure interfaces of an Edge Node, one block for each interface. Each interface used by an application or by EVE on the edge node must be specified in the EdgeNode configuration. The available interfaces are specified in the Device Model used by the device. The following are some notable attributes in the interface
block:- intf_name
- Mandatory attribute. Name of the interface.
- intf_usage
- The following are the different types of interface usage values
- ADAPTER_USAGE_MANAGEMENT
- The Interface is managed by EVE-OS but can be used by both Management and Application instances.
- ADAPTER_USAGE_APP_DIRECT
- The Interface is managed by the Application Instance using its own driver.
- The Interface can be assigned to only one Application Instance at a time.
- ADAPTER_USAGE_APP_SHARED
- The Interface can be used by multiple Application Instances simultaneously, but not by EVE-OS.
- ADAPTER_USAGE_DISABLED
- Neither EVE nor Application Instances can use the interface. The interface is disabled.
- ADAPTER_USAGE_MANAGEMENT
- The following are the different types of interface usage values
- netname
- Name of the Network object to use for the interface if
intf_usage
is ADAPTER_USAGE_MANAGEMENT - if
netname
is not specified for management interfaces (usage=ADAPTER_USAGE_MANAGEMENT), the default network for the project is used.
- Name of the Network object to use for the interface if
- tags
- Specify tags to be used in policies.
resource "zedcloud_network" "Default-Network" {
name = "default-ipv4-network"
<snip>
}
resource "zedcloud_network" "dhcp-passthru-network" {
name = "default-ipv4-network"
<snip>
}
resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
interface {
intf_name = "eth0"
intf_usage = "ADAPTER_USAGE_MANAGEMENT"
tags = {
"intf-tag1" = "tag-value1"
"intf-tag2" = "tag-value2"
}
}
interface {
netname = zedcloud_network.Default-Network.name
intfname = "eth0"
intf_usage = "ADAPTER_USAGE_MANAGEMENT"
}
interface {
intfname = "eth1"
intf_usage = "ADAPTER_USAGE_DISABLED"
}
interface {
intfname = "USB1"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
interface {
intfname = "GPU"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
interface {
intfname = "GPU-Audio"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
interface {
intfname = "eth5"
intf_usage = "ADAPTER_USAGE_DISABLED"
},
interface {
intfname = "wlan0"
intf_usage = "ADAPTER_USAGE_DISABLED"
},
interface {
netname": "default-VZN-APN"
intfname = "wwan0"
intf_usage = "ADAPTER_USAGE_MANAGEMENT",
},
interface {
netname": zedcloud_network.dhcp-passthru-network.name
intfname = "eth1"
intf_usage = "ADAPTER_USAGE_APP_SHARED"
},
interface {
intfname = "VGA"
intf_usage = "ADAPTER_USAGE_APP_DIRECT"
},
<snip>
}
6.3.6. Configure Device Location
Optional Configuration. The location of the device can be specified using the dev_location block. The following is an example of using
dev_location
blocks.resource "zedcloud_edgenode" "Sample-Device" {
name = "TF-Sample-Device"
<snip>
dev_location {
city = "San Jose"
country = "USA"
free_loc = ""
hostname = "sample-device"
latlong = ""
loc = ""
org = "Zededa Engineering"
postal = "95116"
region = "Alameda County"
underlay_ip = "10.1.1.1"
}
<snip>
}
6.4. Volume Instances
Volume Instance depends on the following objects:
-
Edge Node (
zedcloud_edgenode
) -
Image (
zedcloud_image
)
The following are some notable attributes of
(zedcloud_volume_instance)
:accessmode
- The following types of access modes are supported:
- VOLUME_INSTANCE_ACCESS_MODE_READWRITE
- VOLUME_INSTANCE_ACCESS_MODE_READONLY
- VOLUME_INSTANCE_ACCESS_MODE_MULTIREAD_SINGLEWRITE
- The following types of access modes are supported:
device_id
- id of
zedcloud_edgenode
- It is recommended to use implicit dependency on a data source or resource of type
zedcloud_edgenode
- id of
image
- name of zedcloud_image
- It is recommended to use implicit dependency on a data source or resource of type
zedcloud_image
implicit
- Create implicit volume if true
multiattach
- Allow volume instance to be attached to. multiple Application Instances
type
- The following Volume Instance Types are supported:
-
VOLUME_INSTANCE_TYPE_EMPTYDIR
-
VOLUME_INSTANCE_TYPE_BLOCKSTORAGE
-
VOLUME_INSTANCE_TYPE_HOSTFS
-
VOLUME_INSTANCE_TYPE_TMPFS
-
VOLUME_INSTANCE_TYPE_SECRET
-
VOLUME_INSTANCE_TYPE_NFS
-
VOLUME_INSTANCE_TYPE_AWS_BLOCK_STORAGE
-
VOLUME_INSTANCE_TYPE_CONTENT_TREE
-
- The following Volume Instance Types are supported:
resource "zedcloud_edgenode" "TF-sample-edgenode" {
name = "tf-sample-edgenode"
<snip>
}
resource "zedcloud_image" "TF-sample-image" {
name = "tf-sample-image"
<snip>
}
resource "zedcloud_volume_instance" "TF-sample-vol-inst-RO-content-tree" {
accessmode = "VOLUME_INSTANCE_ACCESS_MODE_READONLY"
description = "Immutable Volume"
device_id = zedcloud_edgenode.TF-sample-edgenode
image = zedcloud_image.name
implicit = true
multiattach = false
name = "sample-volinst-1"
project_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
size_bytes = "140443648"
title = "Sample Title"
type = "VOLUME_INSTANCE_TYPE_CONTENT_TREE"
}
6.5. Edge Application
Edge Application object depends on Image Object (
zedcloud_image
)The following diagram illustrates the interaction between edge application configuration-related objects only.

Terraform resource zedcloud_edgeapp has a notable difference from resource definitions for other ZEDEDA CLOUD objects. The EdgeApp manifest is stored in an external file. The image used by the app is specified in the manifest file. There needs to be an explicit dependency on the image using the
depends_on
block.The following are the notable attributes of
zedcloud_edgeapp
:- manifest
- Inline Definition of the app manifest. Only one manifest or manifest_file must be specified.
- manifest_file
- Location of the manifest file. Used when app-manifest is stored in a file instead of defining it inline in terraform. Only one manifest or manifest_file must be specified.
- user_defined_version
- The version of the application is specified by the user.
- When changes are made to the manifest file, there should be a change to user_defined_version to trigger Terraform to re-process the manifest.
Example of Edge-App definition using the inline manifest definition:
resource "zedcloud_edgeapp" "ExampleApp" { name = "sampleName" title = "Sample Title" description = "Sample Description" user_defined_version = "1.1" manifest { apptype = "APP_TYPE_VM" deployment_type = "DEPLOYMENT_TYPE_STAND_ALONE" description = "Sample Description" enablevnc = true name = "sampleName" vmmode = "HV_HVM" configuration { custom_config { add = true allow_storage_resize = true field_delimiter = "##" name = "cloud-init" override = false template = "Sample Template" variable_group { name = "Default Group 1" required = true variable { default = "www.example.com" encode = "FILE_ENCODING_UNSPECIFIED" format = "VARIABLE_FORMAT_TEXT" label = "SampleVariable" max_length = "200" name = "myVar" required = true } } } } image { cleartext = false drvtype = "HDD" ignorepurge = false imagename = "SampleImage" maxsize = 52428800 preserve = false readonly = false target = "Disk" } interface { directattach = false name = "eth0" optional = false privateip = false acl { match { type = "ip" value = "0.0.0.0/0" } } } interface { directattach = false name = "eth1" optional = false privateip = false acl { match { type = "ip" value = "0.0.0.0/0" } } } interface { directattach = false name = "eth2" optional = false privateip = false acl { match { type = "ip" value = "0.0.0.0/0" } } } interface { directattach = false name = "eth3" optional = false privateip = false acl { match { type = "ip" value = "0.0.0.0/0" } } } owner { company = "ZEDEDA Inc." email = "sample@sample.com" user = "Sample User" website = "www.zededa.com" } resource { name = "resourceType" value = "Custom" } resource { name = "cpus" value = "2" } resource { name = "memory" value = "4194304.00" } resource { name = "storage" value = "104857600.00" } } }
Example of Edge-App definition using an external manifest file:
resource "zedcloud_edgeapp" "TF-sample-app" {
name = "TF-sample-app"
title = "TF-sample-app"
description = "TF-sample-app"
manifest_file = "./TF-sample-app-manifest.json"
user_defined_version = "1.0"
depends_on = [
zedcloud_image.TF-sample-image,
]
}
6.6. Network Instances
Network Instance object depends on Edge Node (
zedcloud_edgenode
). The following are some of the notable fields in a Network Instance:- ip
-
- Specify DHCP Server Configuration to be used by EVE to service DHCP client requests. It has the following attributes:
-
-
- dhcp_range
-
-
-
-
- This block specified the range of IP addresses to service DHCP client requests from App Instance.
-
-
-
-
- dns
-
-
-
-
- Specify a list of DNS servers to be sent in the used by the edge node
-
-
-
-
- domain
-
-
-
-
- Specify the Domain to be used in DHCP response.
-
-
-
-
- gateway
-
-
-
-
- Gateway IP address
-
-
-
-
- ntp
-
-
-
-
- NTP server address
-
-
-
-
- subnet
-
-
-
-
- The subnet of the IP address
-
-
- kind
-
- The following kinds of network instances are supported:
-
-
- NETWORK_INSTANCE_KIND_SWITCH
-
-
-
- NETWORK_INSTANCE_KIND_LOCAL
-
- type
-
- DHCP type The following values are supported:
-
-
- NETWORK_INSTANCE_DHCP_TYPE_UNSPECIFIED
-
-
-
- NETWORK_INSTANCE_DHCP_TYPE_V4
-
-
-
- NETWORK_INSTANCE_DHCP_TYPE_V6
-
6.6.1 Configuring Local (NAT) Network Instance
The following is an example configuration for a LOCAL (NAT) Network Instance.
resource "zedcloud_network_instance" "TF-Sample-test-full" {
name = "TF-Sample-test-full"
title = "default-gcp-alpha-acme-kalyan-1"
description = "default-gcp-alpha-acme-kalyan-1"
kind = "NETWORK_INSTANCE_KIND_LOCAL"
type = "NETWORK_INSTANCE_DHCP_TYPE_V4"
device_id = zedcloud_edgenode.Sample-Device.id
// Configure DHCP parameters for the Network Instance.
ip {
dhcp_range {
end = "10.10.1.0"
start = "10.10.1.255"
}
dns = [
"www.tftestdns1.com",
"www.tftestdns2.com"
]
domain = "tftest.com"
gateway = "10.10.1.1"
ntp = "10.10.1.2"
subnet = "10.10.1.0/24"
}
}
6.6.2 Configuring Switch Network Instance
The following is an example configuration for a Switch Network Instance.
resource "zedcloud_network_instance" "TF-nwinst-switch-1" {
name = "sample-ni-switch-1"
description = "sample-ni-switch-1"
title = "sample-ni-switch-1"
device_id = data.zedcloud_edgenode.data-Sample-Device.id
kind = "NETWORK_INSTANCE_KIND_SWITCH"
type = "NETWORK_INSTANCE_DHCP_TYPE_V4"
}
6.7. Edge Application Instance
The following diagram illustrates the interaction between edge application instance configuration-related objects only.

As illustrated above, the Edge Application Instance depends on the following ZEDEDA CLOUD objects:
-
Edge Node
-
Edge App
-
Network Instances
-
Volume Instances
The following are some notable attributes for Terraform Resource
zedcloud_application_instance.
- activate
- Used to activate (set to true)/deactivate (set to false) an Edge Application Instance. This MUST be set to true for the App instance to be active.
- app_id
- id of the Edge Application Object
- app_type
- Type of Application. The following application types are supported:
- APP_TYPE_VM
- Used to create a VM application
- APP_TYPE_VM_RUNTIME
- Used for Kubernetes Cluster modules.
- APP_TYPE_CONTAINER
- Used for Container Applications
- APP_TYPE_MODULE
- Used for modules like Azure IoT Edge
- APP_TYPE_VM
- Type of Application. The following application types are supported:
- custom_config
- configuration to customize the Edge Application Instance. This is passed to the cloud_init module of the application.
- device_id
- id of the Edge Node running the Edge Application Instance
- interface
- Configuration for the interfaces used by the Edge Application Instance.
- remote_console
- Enable (true) or Disable (false) remote console access to the Edge Application Instance.
6.7.1. Configuring Edge Application Instance Interfaces
The
interface
block is used to configure the interfaces used by the Edge Application Instance. The following are some notable attributes of the interface block.- intfname
- Environment Name of the Interface as specified in the Edge App Manifest
- io
- Physical adapter configuration. This is required if
directattach
istrue
- Physical adapter configuration. This is required if
- netinstname
- Name of network instance to be used for the interface.
The following is an example Interface block:
interface {
intfname = "indirect"
netinstname = zedcloud_network_instance.default-nwinst.name
}
interface {
intfname = virtualNIC"
netinstname = "truck-oslc-h-5555-2-sw1"
}
interface = {
intfname = "GPU"
// NOTE - Since directattach = true here, it is required to set io block
io {
name = "GPU"
type = "IO_TYPE_OTHER"
}
}
interface {
intfname = "USB"
io {
name = "USB1",
type = "IO_TYPE_USB"
}
}
6.7.2. Virtual Machine type of Edge Application Instance
The following is an example of a configuration for an Edge Application Instance of type VM, with one interface:
resource "zedcloud_edgeapp_instance" "Sample-EdgeAppInstance" {
name = "TF-Sample-Resource-EdgeAppInstance"
activate = true
app_type = "APP_TYPE_VM"
app_id = zedcloud_edgeapp.TF-sample-app.id
description = "TerraForm Sample App Instance - TESTING Update"
device_id = zedcloud_edgenode.Sample-Device.id
interfaces {
intfname = "indirect"
netinstname = zedcloud_network_instance.default-nwinst.name
}
title = "TerraForm Sample App Instance"
remote_console = true
}
6.8. Datastore
Datastores are only supported as a data source. For more information on Datastores, click here. Following is an example of a Datastore as a data source:
data "zedcloud_datastore" "sample-datastore" {
name = "sample-datastore"
}
7. Error Handling
If there is an error in any of the operations, the provider returns an appropriate error for the operation. If the request to ZEDEDA CLOUD fails, the error code, and any error strings returned by ZEDEDA CLOUD, will be returned to Terraform.
When an operation fails, the user should look at the error reported by Terraform and take the necessary action. The errors provided by
terraform apply
will have the following information:- The Resource in the .tf file that ran into the error
with zedcloud_edgenode.Sample-Device,
on onedevice_oneappinst.tf line 31, in resource "zedcloud_edgenode" "Sample-Device":
31: resource "zedcloud_edgenode" "Sample-Device" {
- The Error message provided by the provider
- The error message should provide enough details for the user to understand and fix the error.
Error: [ERROR] 3ab53292-ad51-4807-9ae7-d2882cc3c600 Edge Node
( id: gcp-alpha-acme-kalyan-1) Update Failed. BaseOsImage Publish failed.
Err: Request FAILED. StatusCode: 400 Bad Request. Rsp Error Details:
Details: Entry not found, EC: BadReqBody