Allow iaas_conmfiguration["kms_key_arn"]

[agregory999]

Looks like we get an error setting an AWS custom key after deployment. The code doesn't seem to have it:

type AWSIaaSConfiguration struct { AccessKeyID string url:"iaas_configuration[access_key_id],omitempty" json:"access_key_id" SecretAccessKey string url:"iaas_configuration[secret_access_key],omitempty" json:"secret_access_key" IAMInstanceProfile string url:"iaas_configuration[iam_instance_profile],omitempty" json:"iam_instance_profile" VpcID string url:"iaas_configuration[vpc_id],omitempty" json:"vpc_id" SecurityGroup string url:"iaas_configuration[security_group],omitempty" json:"security_group" KeyPairName string url:"iaas_configuration[key_pair_name],omitempty" json:"key_pair_name" Region string url:"iaas_configuration[region],omitempty" json:"region" Encrypted *bool url:"iaas_configuration[encrypted],omitempty" json:"encrypted" }

The following API call works after deployment: ubuntu@ip-192-168-0-248:~$ curl /api/v0/staged/director/properties" \ -X PUT -H "Authorization: Bearer ${UAA_TOKEN}" -H "Content-Type: application/json" -k \ -d '{ "iaas_configuration": { "encrypted": true, "kms_key_arn": "" } }'

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

[jtarchie]

@agregory999, are you able to use configure-director instead of configure-bosh. The later is being deprecated in favor of not supporting custom structs. The configure-director command just applies the JSON payload raw, rather than parsing it into structs, and then regenerating the JSON for the API endpoint.

[ljfranklin]

@agregory999 yep, please try using om configure-director as JT suggested as it is more permissive. I'll look into adding a big DEPRECATED warning next to configure-bosh.

[agregory999]

Not sure I understand correctly. We may need to look at layered tools, as the customer originally reported that their automation scripts using om-linux were failing to set that property. I tested with the Opsman API, but somehow we will need to look at all upstream tools.

[ljfranklin]

The om CLI supports two subcommands with names that are unfortunately close together: om configure-director and om configure-bosh. om configure-bosh was the original command that existed prior to the OpsMgr API and submitted data to a web form. The newer, better version is om configure-director which uses the OpsMgr API and supports a wider range of options. So the fix in this case is to keep using om, but replace om configure-bosh calls with om configure-director in your scripts.

[jtarchie]

@agregory999, is this still an issue?

[jtarchie]

Since configure-bosh is being removed in this PR and configure-director can handle this property, I'm going to close this issue.