purge_config not working for some classes

Bug #1612009 reported by Brent Eagles
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
puppet-neutron
Fix Released
High
Brent Eagles
puppet-nova
Fix Released
Undecided
Brent Eagles
puppet-openstacklib
Fix Released
High
Brent Eagles

Bug Description

Remnants of old configuration and/or garbage settings are not being cleaned up when purge_config is set to true for some classes including, but not limited to ::nova and ::neutron.

The code for the providers for these classes differ from the majority of other providers.

Revision history for this message
Brent Eagles (beagles) wrote :

When investigating this issue, a "can't generate additional resources" error mentioning namevar method not found was displayed. Adding a namevar method to the provider code resolves the error, after which purging also works for that class. e.g. https://review.openstack.org/#/c/353802/

Changed in puppet-neutron:
assignee: nobody → Brent Eagles (beagles)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to puppet-nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/353814

Changed in puppet-nova:
assignee: nobody → Brent Eagles (beagles)
status: New → In Progress
Revision history for this message
Brent Eagles (beagles) wrote :

Further info:

I've tried a few variations on fixes, including changing puppet-neutron/lib/puppet/provider/neutron_config.rb to use the ini_setting provider like the other provider implementations do. For example:

Puppet::Type.type(:neutron_config).provide(
  :openstackconfig,
  :parent => Puppet::Type.type(:openstack_config).provider(:ini_setting)
) do

...

What happens is that neutron class parameters such as neutron::bind_port which are defaulted to $::os_service_default result in entries like:

bind_port = ["<SERVICE DEFAULT>"]

in the config file.

Actually it appears that all class parameters that have a default of $::os_service_default are resulting in configuration entries being added with this value. In other words, they are not behaving as though they were unset.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on puppet-nova (master)

Change abandoned by Brent Eagles (<email address hidden>) on branch: master
Review: https://review.openstack.org/353814
Reason: https://review.openstack.org/#/c/354096/ should handle this.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on puppet-neutron (master)

Change abandoned by Brent Eagles (<email address hidden>) on branch: master
Review: https://review.openstack.org/353802
Reason: https://review.openstack.org/#/c/354096/ should handle this.

Revision history for this message
Brent Eagles (beagles) wrote :

This is fixed by adding the namevar method https://review.openstack.org/#/c/354096/ as opposed to the individual modules.

Changed in puppet-openstacklib:
status: New → In Progress
assignee: nobody → Brent Eagles (beagles)
Changed in puppet-neutron:
importance: Undecided → High
Changed in puppet-openstacklib:
importance: Undecided → High
Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/puppet-openstacklib 9.2.0

This issue was fixed in the openstack/puppet-openstacklib 9.2.0 release.

Brent Eagles (beagles)
Changed in puppet-openstacklib:
status: In Progress → Fix Released
Changed in puppet-neutron:
status: In Progress → Fix Released
Changed in puppet-nova:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.