Scope-related warnings from nova::vncproxy::common

Bug #1506066 reported by Nick Jones
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

The use of the 'pick' function to select variables from other classes can throw scope-related warnings on nodes that don't have all of those classes included, as 'pick' attempts to qualify all variables passed before selecting the first defined value. For example:

Nodes that have the nova::compute class included and on which we want to enable the VNC service (the default), i.e a compute node, get nova::vncproxy::common included automatically, but we don't include nova::vncproxy so we see the following error:

Warning: Scope(Class[Nova::Vncproxy::Common]): Could not look up qualified variable '::nova::vncproxy::host'; class ::nova::vncproxy has not been evaluated

The reverse is true on a control node where we do have nova::vncproxy included but not nova::compute:

Warning: Scope(Class[Nova::Vncproxy::Common]): Could not look up qualified variable '::nova::compute::vncproxy_host'; class ::nova::compute has not been evaluated

Tested with Puppet 3.8.3, puppetlabs-stdlib version 4.9.0.

Nick Jones (yankcrime)
description: updated
description: updated
description: updated
Changed in puppet-nova:
status: New → Confirmed
importance: Undecided → Medium
Nate Potter (ntpttr)
Changed in puppet-nova:
assignee: nobody → Nate Potter (ntpttr)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to puppet-nova (master)

Fix proposed to branch: master

Changed in puppet-nova:
status: Confirmed → In Progress
Revision history for this message
Alex Schultz (alex-schultz) wrote :

Unfortunately I think this is a puppet processing issue with the test. We probably need to restructure how we recommend a user set this variable. Currently it appears that despite the fact we are including both nova::compute and nova::vncproxy, when the nova::vncproxy::common is actually included, it has not processed both of the previously mentioned classes. This leads to our warnings. I'm not sure the best way to force puppet to process the evaluation of those two classes prior to processing nova::vncproxy::common. Especially since nova::vncproxy::common is included by both of those classes.

Revision history for this message
Cody Herriges (ody-cat) wrote :

Data look ups and the definition of variables is done at parse time so controlled only by line order. Puppet will dive into a class and start parsing once you do any type of "include". I know of no other way to manipulate this short of moving code around so it happens before other code.

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

Change abandoned by Nate Potter (<email address hidden>) on branch: master
Reason: This approach won't solve the problem.

Cody Herriges (ody-cat)
Changed in puppet-nova:
status: In Progress → Confirmed
Revision history for this message
Nate Potter (ntpttr) wrote :

Taking myself off this one because I don't have the time to figure out another way to solve the problem for now

Changed in puppet-nova:
assignee: Nate Potter (ntpttr) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers