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
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: 2017-08-16 13:29 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-16 13:29:29 EDT
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
Comment 7 Chris Pelland 2017-08-16 13:29:29 EDT
This bug has been open for more than a year and is assigned to an older release of CloudForms. 

If you would like to keep this Bugzilla open and if the issue is still present in the latest version of the product, please file a new Bugzilla which will be added and assigned to the latest release of CloudForms.

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