staged-director-config cannot be used for configure-director on vsphere

[kcboyle]

when you pull down staged-director-config, az-configuration gets populated with iaas_configuration_guid (see #190) Example:

az-configuration:
- name: zone-1
  clusters:
  - cluster: Compute-AZ1
    resource_pool: ""
  iaas_configuration_guid: 4a035e9b035037ce5600

This becomes an issue when you tear down the environment, revert changes before deploying the director, or are using the configuration as a template for other foundation deployments.

This is only an issue when using the iaas-configuration top-level key block (not nested as iaas_configuration under properties-configuration) and should only be an issue on vSphere. Example iaas-configurations as pulled down from staged-director-config

iaas-configurations:
- additional_cloud_properties: {}
  bosh_disk_path: pcf_disk
  bosh_template_folder: pcf_templates
  bosh_vm_folder: pcf_vms
  datacenter: ((iaas-configurations_0_datacenter))
  disk_type: thin
  ephemeral_datastores_string: ((iaas-configurations_0_ephemeral_datastores_string))
  name: ((iaas-configurations_0_name))
  nsx_address: ((iaas-configurations_0_nsx_address))
  nsx_mode: nsx-t
  nsx_networking_enabled: true
  nsx_username: ((iaas-configurations_0_nsx_username))
  nsx_password: ((iaas-configurations_0_nsx_password))
  persistent_datastores_string: ((iaas-configurations_0_persistent_datastores_string))
  ssl_verification_enabled: false
  vcenter_host: ((iaas-configurations_0_vcenter_host))
  vcenter_password: ((iaas-configurations_0_vcenter_password))
  vcenter_username: ((iaas-configurations_0_vcenter_username))

One way someone got it working was to add:

az-configuration:
- name: zone-1
  clusters:
  - cluster: Compute-AZ1
    resource_pool: ""
  iaas_configuration: 
  - name: default

we should address issue #190 to address the issue here for vSphere.

Required tests:

1. run the following workflow as an integration test

   • configure the director manually
   • staged-director-config -> director.yml
   • revert changes
   • configure-director with director.yml
   • AC: no failures should occur

2. run the following workflow as an integration test

   • configure the director manually
   • add a second iaas_configuration to the environment (a clone of the first with a different name is O.K.
   • staged-director-config -> director.yml
   • revert changes
   • configure-director with director.yml
   • AC: no failures should occur

3. all unit tests required to test the behavior changes

[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.

[FlorentFlament]

Hi,

We just went into some similar issue (willing to use a staged-director-config as a template for other foundations).

When using such az-configuration block:

az-configuration:
- name: zone-1
  clusters:
  - cluster: Compute-AZ1
    resource_pool: ""
  iaas_configuration: 
  - name: default

We get the following error, when using the om configure-director command:

{"errors": {"base": {"There is an error on an availability_zone."], "iaas_connfiguration_guid":["can't be blank"]}}

Note that we have several IaaS configurations, and several AZs per IaaS config. We are currently running Opsman 2.6.9 and the om cli 4.0.1.

Regards,
Florent

[will-gant]

We're hitting the same issue. We're using a single IaaS configuration on vSphere, and we get...

{"errors": {"base": {"There is an error on an availability_zone."], "iaas_connfiguration_guid":["can't be blank"]}}

... regardless of whether we put iaas-configurations at a top level, iaas_configuration nested under properties-configuration, or any of the other permutations suggested here.

For now (we're pipelining this with Concourse) we're just going to settle for retrieving the value directly from the Opsman with an additional Concourse task, but it would be great if it wasn't necessary to provide this value at all. As long as it is required, it looks like this issue makes it quite awkward to use Platform Automation to configure the director on vSphere.

[anEXPer]

I just wanted to give y'all an update - we're working on figuring out the right thing to do here, it's a little technically complicated, but we're on it.

[kcboyle]

This has been fixed in 4.1.0. Closing this issue.

[will-gant]

Thanks :)