V1.6.2: redfish provider

Mon, 01 Jan 0001 00:00:00 +0000

redfish Provider

Terraform Provider Redfish

Information about Redfish Terraform Provider

This guide will explain different parts of the provider and will give an overview about how the provider is built.

1. Provider’s way of operation

When you think of Terraform, normally operators tend to think that the way a provider connects with a cloud provider is via a single endpoint. Well, actually that’s the way it works. Cloud providers provide an endpoint and operators point to that endpoint when configuring terraform.

  +-----------------+
  | Cloud provider  |
  +-------+---------+
          ^
          |
          |
+---------+----------+
| Terraform provider |
+--------------------+

With the Redfish Terraform Provider, that operating model has been changed because of the way the provider interacts with the infrastructure (Redfish endpoints). In a regular scenario (for instance a datacenter), operators don’t just have one endpoint, but a bunch of them. Each redfish endpoint corresponds to each physical server.

+------------------+     +------------------+      ...N        +------------------+
| PowerEdge Server |     | PowerEdge Server |  +-----------+   | PowerEdge Server |
| with Redfish API |     | with Redfish API |                  | with Redfish API |
+-------+----------+     +--------+---------+                  +---------+--------+
        ^                         ^                   ^                  ^
        |                         |                   |                  |
        +-------------------------+----------+--------+------------------+
                                             |
                                             |
                                  +----------+---------+
                                  | Terraform Provider |
                                  +--------------------+

How we overcome this

Normally the provider is initialized in the provider block, giving it your cloud credentials to deal with the infrastructure. Something like this:

provider "aws" {
	region     = "eu-west-1"
	access_key = "myaccesskey"
	secret_key = "mysecretkey"
}

When that is done, then operators would start writing the resources they want to deploy in those regions.

With this terraform redfish provider a different approach had to be followed since there are multiple endpoints. What has been done (and kudos to Kyriakos Oikonomakos from Hashicorp for proposing this) was to initialize the client at the resource level. This allows operators to manage different servers from one central point. Take a look into this example:

users.tf

resource "redfish_user_account" "rr" {
  for_each = var.rack1

  redfish_server {
    user         = each.value.user
    password     = each.value.password
    endpoint     = each.value.endpoint
    ssl_insecure = each.value.ssl_insecure
  }

  user_id  = "4"
  username = "test"
  password = "Test@123"
  role_id  = "Operator"
  enabled  = true
}

terraform.tfvars

rack1 = {
  "my-server-1" = {
    user         = "admin"
    password     = "passw0rd"
    endpoint     = "https://my-server-1.myawesomecompany.org"
    ssl_insecure = true
  },
  "my-server-2" = {
    user         = "admin"
    password     = "passw0rd"
    endpoint     = "https://my-server-2.myawesomecompany.org"
    ssl_insecure = true
  },
  "my-server-3" = {
    user         = "admin"
    password     = "passw0rd"
    endpoint     = "https:://[2001:db8:a::123]"
    ssl_insecure = true
  },
}

By doing this, operators create two users on two different servers using this provider and the Redfish API. Remember, in every CRUD operation, the client must be initialized.

Overwriting client credentials

There might be scenarios where operators have the same credentials for all machines they want to manage. In that case they don’t need to repeatedly write the user and password for all servers. They can write their credentials at the provider block level.

provider "redfish" {
    user = "root"
    password = "passw0rd"
}

After the user specifies their credentials, they will next need to define the infrastructure. Instead of defining credentials for each endpoint they need only provide the endpoint and ssl_insecure values:

rack1 = {
    "my-server-1" = {
        endpoint = "https://my-server-1.myawesomecompany.org"
        ssl_insecure = true
    },
    "my-server-2" = {
        endpoint = "https://my-server-2.myawesomecompany.org"
        ssl_insecure = true
    },
}

Terraform will always use the most specific client values. In the case client credentials are defined at both the provider block and resource level, the credentials defined at the resource level will be used.

Example Usage

provider.tf

/*
Copyright (c) 2022-2026 Dell Inc., or its subsidiaries. All Rights Reserved.

Licensed under the Mozilla Public License Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://mozilla.org/MPL/2.0/


Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

terraform {
  required_providers {
    redfish = {
      version = "1.6.2"
      source  = "registry.terraform.io/dell/redfish"
    }
  }
}

provider "redfish" {
  # # `redfish_servers` is used to align with enhancements to password management.
  # # Map of server BMCs with their alias keys and respective user credentials.
  # # This is required when resource/datasource's `redfish_alias` is not null
  # redfish_servers  = var.rack1
}

variables.tf

/*
Copyright (c) 2022-2025 Dell Inc., or its subsidiaries. All Rights Reserved.

Licensed under the Mozilla Public License Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://mozilla.org/MPL/2.0/


Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/


variable "rack1" {
  type = map(object({
    user         = string
    password     = string
    endpoint     = string
    ssl_insecure = bool
  }))
}

Schema

Optional

password (String, Sensitive) This field is the password related to the user given
redfish_servers (Attributes Map) Map of server BMCs with their alias keys and respective user credentials. This is required when resource/datasource’s redfish_alias is not null (see below for nested schema)
user (String) This field is the user to login against the redfish API

Nested Schema for `redfish_servers`

Required:

endpoint (String) Server BMC IP address or hostname

Optional:

password (String, Sensitive) User password for login
ssl_insecure (Boolean) This field indicates whether the SSL/TLS certificate must be verified or not
user (String) User name for login

V1.6.2: Data Sources

Mon, 01 Jan 0001 00:00:00 +0000

In Terraform, a data source is a way to retrieve information about an entity that is not managed by the current Terraform configuration. Data sources provide dynamic information that can be used elsewhere in the Terraform configuration. Data sources are used to get information about resources external to Terraform and use them to set up Terraform resources. For example, a volume Dell Storage system exposes. Data sources are accessed via a special kind of resource known as a data resource, declared using a data block.Each data resource is associated with a single entity, which determines the kind of object it reads and what query constraint arguments are available. For further details, please check out https://developer.hashicorp.com/terraform/language/data-sources

V1.6.2: Resources

Mon, 01 Jan 0001 00:00:00 +0000

In Terraform, a resource is an abstract entity that represents a real-world object, such as a virtual machine, file, user, or volume. A resource belongs to a provider, accepts arguments, outputs attributes, and has a lifecycle. Resource blocks are used to declare resources in Terraform, and each block describes one or more infrastructure objects. For further details, please check out https://developer.hashicorp.com/terraform/language/resources

V1.6.2: Examples

Mon, 01 Jan 0001 00:00:00 +0000

Dell Technologies – Product Guide

V1.6.2: redfish provider

redfish Provider

Information about Redfish Terraform Provider

1. Provider’s way of operation

How we overcome this

Overwriting client credentials

Example Usage

Schema

Optional

Nested Schema for redfish_servers

V1.6.2: Data Sources

V1.6.2: Resources

V1.6.2: Examples

Nested Schema for `redfish_servers`