Bug 1293977 - using prov.set_customization_spec wipes networking options from prov.options [NEEDINFO]
using prov.set_customization_spec wipes networking options from prov.options
Status: NEW
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Documentation (Show other bugs)
All All
high Severity high
: GA
: 5.6.0
Assigned To: Red Hat CloudForms Documentation
Red Hat CloudForms Documentation
Depends On:
  Show dependency treegraph
Reported: 2015-12-23 16:11 EST by Josh Carter
Modified: 2016-05-14 15:28 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jocarter: needinfo? (gmccullo)

Attachments (Terms of Use)

  None (edit)
Description Josh Carter 2015-12-23 16:11:47 EST
Description of problem:

When using prov.set_customization_spec(customization_spec) in vmware_customizerequest the values of dns_servers, dns_suffixes, gateway, ip_addr, subnet_mask are set to nil.

I've tried it with 

prov.set_customization_spec('DHCP Linux Customization Spec', true)


prov.set_customization_spec('Static Linux Customization Spec', false)

and what seems to be happening is that it is replacing the prov options with whatever is in the customization spec, so if you use a DHCP spec, it wipes out the options, if you use a Static Spec you'll get prov.options[:ip_addr] will be equal to whatever was in the spec.

set_customization_spec -> refresh_field_values -> update_custom_spec -> update_fields_from_spec_networking

Eventually what happens is that update_fields_from_spec_networking sets things to the values in the spec.

See attached logs with prepended code snippets.

I've modified set_customization_field_from_spec in vmdb/app/models/miq_provision_virt_workflow.rb to only set it if its not already set, but I really think if it was working correctly this chunk of code probably wouldn't run to begin with.

# app/models/miq_provision_virt_workflow.rb

  def set_customization_field_from_spec(data_value, dlg_field, dialog)
    field_hash  = dialog[:fields][dlg_field]
    data_type   = field_hash[:data_type]
    cust_method = "custom_#{dlg_field}"

    if self.respond_to?(cust_method)
      send(cust_method, field_hash, data_value)
      value = case data_type
              when :boolean then data_value == "true"
              when :integer then data_value.to_i_with_method
              when :string  then data_value.to_s
              else               data_value

      if field_hash.key?(:values)
        $log.info("set_value_from_list(#{dlg_field}, #{field_hash}, #{value})")
        set_value_from_list(dlg_field, field_hash, value)
        $log.info("@values[#{dlg_field}] = #{@values[dlg_field]}")
        $log.info("value = #{value}")
        @values[dlg_field] = value unless @values[dlg_field]
        $log.info("@values[#{dlg_field}] = #{@values[dlg_field]}")

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

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 2 Greg McCullough 2015-12-23 16:54:09 EST
Josh - This code is currently working as designed.  Automate methods use the same exact code the UI workflow uses when selecting a customization spec.  If the code did not set these values the UI would only ever display the values from the first spec and would never update if you selected a new spec which would not be the expected behavior.

As a work-around I would suggest duplicating the provision options before calling the set_customization_spec method and then resetting the required values.

Here is an example of what I am suggesting (has not been tested):

my_options = prov.options.dup
prov.set_customization_spec('DHCP Linux Customization Spec', true)
[:dns_servers, :gateway, :subnet_mask, :ip_addr].each do |key|
  prov.set_option(key, my_options[key])
Comment 3 Josh Carter 2015-12-28 10:17:15 EST

I had been doing some testing with that and that does appear to work somewhat. I've noticed that at least the ``linux_domain_name`` setting is only applied if I

prov.set_option(:sysprep_spec_override, [true, 1])

before I call

prov.set_customization_spec(customization_spec, true) # true or false doesn't seem to matter

Note You need to log in before you can comment on or make changes to this bug.