Bug 1293977 - using prov.set_customization_spec wipes networking options from prov.options
Summary: using prov.set_customization_spec wipes networking options from prov.options
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Documentation
Version: 5.4.0
Hardware: All
OS: All
high
high
Target Milestone: GA
: 5.6.0
Assignee: Red Hat CloudForms Documentation
QA Contact: Red Hat CloudForms Documentation
URL:
Whiteboard: doc:custom:provision
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-23 21:11 UTC by Josh Carter
Modified: 2021-06-10 11:05 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-16 17:29:29 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Josh Carter 2015-12-23 21:11:47 UTC
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)

and

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)
    else
      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
              end

      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)
      else
        $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]}")
      end
    end
  end


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Greg McCullough 2015-12-23 21:54:09 UTC
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])
end

Comment 3 Josh Carter 2015-12-28 15:17:15 UTC

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 17:29:29 UTC
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.

Comment 8 Andrew Dahms 2017-11-08 23:52:30 UTC
Closing old needinfo request.


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