Bug 1302250

Description of problem:
I'm not sure if this is a bug or an RFE, but I don't seem to be able to add any options from the Environment provisioning dialog tab to my vmFields argument in a call to create_provision_request. In particular for a cloud instance provision it would be useful to be able to set options such as :cloud_network or :cloud_tenant.

Looking through the code in miq_provision_virt_workflow I can see that it's hard-coding "values[:placement_auto] = [true, 1]", so there's a possible assumption that Environment processing is not required. Certainly ws_vm_fields does not try to handle any environment fields; there's no ws_environment_fields method to handle the insertion of any environment values. If I try setting the value :cloud_network in my vmFields argument I see the message:

"Unprocessed key <cloud_network> with value <"1000000000002">"

This was probably a reasonable assumption when we purely had Infrastructure VM provisioning, but now with Cloud Instance provisioning to multiple tenants it would be useful to be able to override the auto_placement values.

Version-Release number of selected component (if applicable):
5.5.0.13

How reproducible:
Every time

Steps to Reproduce:
1. Code a call to $evm.execute('create_provision_request', args) with a templateFields argument specifying an OpenStack image name, and a vmFields (arg3) value containing "cloud_network=1000000000002|cloud_tenant=1000000000001" (specify valid object IDs)
2. Call the method
3. 

Actual results:
Observe in log/evm.log:

Unprocessed key <cloud_network> with value <"1000000000002">
Unprocessed key <cloud_tenant> with value <"1000000000001">

Expected results:
The specified cloud_network and cloud_tenant should be set in the provision request.

Additional info:
I note that we can override this behaviour ourselves by passing Environment value as ws_values arguments, and then special-casing them in an openstack_CustomizeRequest, but the need to do this is not intuitive, and not documented.