Cannot Append Machine Parameters

[laltomar]

We need the ability to add new machine parameters when creating a new drp_machine resource. It does not look like this is possible, it looks like only option is to add new profiles to a machine. I tried to add the Params to the the terraform config but that seemed to override the existing machine parameters with new ones as opposed to appending.

Params = { "myparam1" = "param value" }

[sygibson]

@laltomar - one of the easiest ways to check how a call to DRP may work, is to use the drpcli command - it has relatively extensive internal "help" that you can walk through how to use the actions it enables.

In this case - you can see that the params option to manipulating a Machine is designed to get/set all Params on a Machine. What you are likely looking for is an option to set individual Params - if that Param does not exist on the Machine, then it'll append it to the existing list of Params.

Example of getting help:

# drpcli machines | egrep "add |params"
  add           Add the machines param *key* to *blob*
  params        Gets/sets all parameters for the machine```

You can also point your web browser to the Swagger interface on your DRP endpoint, and see more documentation for API calls.  Example URL:

  https://10.10.10.10:8092/swagger-ui

Change the IP:Port pair as appropriate for your own DRP Endpoint.

These all map directly to Terraform/RackN DSL statements.

Please let us know if you have any other questions - or if this doesn't answer your problem.

[laltomar]

Thanks for the response, can you tell me how to do this using the drp_machine resource from the DRP terraform provider. Here is the complete config without parameters, the question is how do I append additional parameters using the terraform config.

`provider "drp" {
api_user = "${var.api_user}"
api_password = "${var.api_password}"
api_url = "${var.api_url}"
}

resource "drp_machine" "mymachine" {
count = 1
Workflow = "centos-base"
Description = "DRP Terraform Filter Sample"
Name = "mymachine.mydomain.net"
filters = [{
name = "Uuid"
jsonvalue = "d6668565-034a-4ee5-9277-50f62beec6de"
}]
add_profiles = [ "dev", "rhel-7-default" ]
decommission_workflow = "discover-base-terraform"
}`

[galthaus]

First and foremost Terraform is very challenging. it has issues about express deep and rich data structures. So, the Params field is really a map of extremely complex structures.

I think you need to do this:

Params = { "myparam1" = "\"param value\"" }

Basically the strings are JSON strings because Terraforom ONLY understand maps of strings.
So, we are cheating to let this work.

We are looking at completely rewriting this to alter state management. Terraform's state management can be really really messy with systems that actually keep track of the state of the system.

[laltomar]

The initial format worked, the issue is it replaces the Params instead of appending. I think you need to have a resource parameter "add_parameters" similar to "add_profiles".

	// Define what profiles to add and remove at destroy
	r.Schema["add_parameters"] = &schema.Schema{
		Type:     schema.TypeMap,
		Optional: true,
	}

         // Simple sample using string
	if params, ok := d.GetOk("add_parameters"); ok {
		for k, v := range params.(map[string]interface{}) {
			m.Params[k] = v.(string)
		}
	}

[zehicle]

@laltomar you are correctly pointing out the state synchronization problem with Terraform exposed in this version of the provider. If we expose native DRP objects for Terraform then it will override/reset DRP changes.

As you suggest, one solution is to provide more "action" type calls that are not state updates to the Terraform state.

We're in the process of building a v2 of this provider that uses the RackN Pool API to avoid sync on the machine state. The Pool API already allows you to inject profiles and params as part of a checkout.

Overall, it should be very simple and it's possible that we'll need to add some actions too. We're not planning to allow full models updates like in v1 because of the state issue.

We'd be happy to work with you on the v2 ideas and using the Pool API. The DRP APIs have come a long way since we wrote v1.

[laltomar]

@zehicle Thanks for the response!

I had a quick read on the pools content plugin, definitely seems to be a good idea. I think the v2 terraform provider based off of pools would work for us as we simply need to add profiles and machine specific parameters when provisioning a drp_machine resource. A couple of more questions:

1. Are you planning on adding additional terraform resources and data sources? I see there are some unit tests in the repo.
2. When is the v2 terraform provider going to be available? I am more than happy to test it out even if it is not fully completed.

Thanks again for the quick responses on this.

Regards,
Larry

[galthaus]

@laltomar - they are all there as resources and providers already in this version. The code as it exists inspects the GO structures and builds the correct models for terraform. Hashicorp can't stand this and the next version will NOT work this way. This is yet another reason that Terraform and Hashicorp are challenges to work with. It must be their way or no way even if you know how to make GO work well.

drp_profile, drp_stage, ..... are all there. The problem is that content packs are a much better mechanism to do infrastructure as code. They are versioned and controlled much better than any terraform plan and state file. So, we are NOT likely to add other models to the v2 provider. We may add a content import. That has some shot of working with the crappy terraform models.