Jira (PUP-7664) "Function lookup() did not find a value for the name 'classes' on node"

41 views
Skip to first unread message

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 4:11:11 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza updated an issue
 
Puppet / CI Blocker PUP-7664
"Function lookup() did not find a value for the name 'classes' on node"
Change By: Moses Mendoza
Summary: puppetserver test failure  "Function lookup() did not find a value for the name 'classes' on node"
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Thomas Hallgren (JIRA)

unread,
Jun 14, 2017, 4:12:03 PM6/14/17
to puppe...@googlegroups.com
Thomas Hallgren commented on CI Blocker PUP-7664
 
Re: "Function lookup() did not find a value for the name 'classes' on node"

Moses Mendoza, I don't recognize this and I'm not able to derive any meaningful clues from the stack trace either other than that a catalog is compiled and a lookup fails. In order to help out, I'll need a way to reproduce and look around. Or, if that's difficult to provide, a server log where DEBUG is enabled (provides lookup explain output).

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 4:14:44 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza updated an issue
Change By: Moses Mendoza
Somewhere in between 78e175e6 and 27fdad2 of puppet, puppet server tests have started failing.

Specifically, https://jenkins-master-prod-1.delivery.puppetlabs.net/job/platform_puppetserver_integration-system_no-conditional_smoke-master/366/LAYOUT=redhat7-64ma-windows2008r2-64a,LDAP_TYPE=default,label=beaker/consoleFull, with output:

{code}
10:26:01 p7145rmqxgo7fs9.delivery.puppetlabs.net (redhat7-64-1) 17:26:01$ curl --silent --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem --key /etc/puppetlabs/puppet/ssl/private_keys/p7145rmqxgo7fs9.delivery.puppetlabs.net.pem --cert /etc/puppetlabs/puppet/ssl/certs/p7145rmqxgo7fs9.delivery.puppetlabs.net.pem https://p7145rmqxgo7fs9.delivery.puppetlabs.net:8140/puppet/v3/catalog/p7145rmqxgo7fs9.delivery.puppetlabs.net?environment=production | python -m json.tool
10:26:01   {
10:26:02       "issue_kind": "RUNTIME_ERROR",
10:26:02       "message": "Server Error: Function lookup() did not find a value for the name 'classes' on node p7145rmqxgo7fs9.delivery.puppetlabs.net"
10:26:02   }
10:26:02 
10:26:02 p7145rmqxgo7fs9.delivery.puppetlabs.net (redhat7-64-1) executed in 1.00 seconds
10:26:02 Minitest::Assertion: FAIL: Expected catalog to contain current_code_id 3aafbd686b0f884f4519de1ebd6fdac5d2454d14..
{code}

On repro, the actual stack trace from logs is https://gist.github.com/MosesMendoza/4cdedf11fb92c137404a29b28d137a48.


*Update*
This is the result of laying down a hiera 5 yaml file in puppet instead of the previous default hiera yaml file provided by the hiera project.

The test does not modify the default hiera yaml file. The previous default file would create a lookup hierarchy, so all the test did was add a data file with entries that would resolve via that hierarchy.

The new default does not specify the same hierarchy, so lookup now fails where it previously succeeded.

Thomas Hallgren (JIRA)

unread,
Jun 14, 2017, 4:17:05 PM6/14/17
to puppe...@googlegroups.com
 
Re: "Function lookup() did not find a value for the name 'classes' on node"

Ah, so in that case, this is actually expected. The layout is no longer using a Hiera 3 config that points into an environment. I would suggest two changes to the test.

1. Stop using the directory `hieradata` and use `data` instead, since that's the default in Hiera 5.
2. Add a hiera.yaml file to the environment with the contents:

---
version: 5

This configuration will use all Hiera 5 defaults, i.e. datadir: data, path: common, and data_hash: yaml_data.

Josh Cooper (JIRA)

unread,
Jun 14, 2017, 4:20:02 PM6/14/17
to puppe...@googlegroups.com

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 4:25:02 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza updated an issue
Change By: Moses Mendoza
Somewhere in between 78e175e6 and 27fdad2 of puppet, puppet server tests have started failing.

Specifically, https://jenkins-master-prod-1.delivery.puppetlabs.net/job/platform_puppetserver_integration-system_no-conditional_smoke-master/366/LAYOUT=redhat7-64ma-windows2008r2-64a,LDAP_TYPE=default,label=beaker/consoleFull, with output:

{code}
10:26:01 p7145rmqxgo7fs9.delivery.puppetlabs.net (redhat7-64-1) 17:26:01$ curl --silent --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem --key /etc/puppetlabs/puppet/ssl/private_keys/p7145rmqxgo7fs9.delivery.puppetlabs.net.pem --cert /etc/puppetlabs/puppet/ssl/certs/p7145rmqxgo7fs9.delivery.puppetlabs.net.pem https://p7145rmqxgo7fs9.delivery.puppetlabs.net:8140/puppet/v3/catalog/p7145rmqxgo7fs9.delivery.puppetlabs.net?environment=production | python -m json.tool
10:26:01   {
10:26:02       "issue_kind": "RUNTIME_ERROR",
10:26:02       "message": "Server Error: Function lookup() did not find a value for the name 'classes' on node p7145rmqxgo7fs9.delivery.puppetlabs.net"
10:26:02   }
10:26:02 
10:26:02 p7145rmqxgo7fs9.delivery.puppetlabs.net (redhat7-64-1) executed in 1.00 seconds
10:26:02 Minitest::Assertion: FAIL: Expected catalog to contain current_code_id 3aafbd686b0f884f4519de1ebd6fdac5d2454d14..
{code}

On repro, the actual stack trace from logs is https://gist.github.com/MosesMendoza/4cdedf11fb92c137404a29b28d137a48.


*Update*
This is the result of laying down a hiera 5 yaml file in puppet instead of the previous default hiera yaml file provided by the hiera project.

This was done in https://github.com/puppetlabs/puppet/commit/7178bf1850c1addc40b5cc31a29aa4add09f34a9. The  puppet install.rb runs after the hiera install.rb during the puppet agent build process, so the hiera.yaml from hiera is overwritten by the hiera.yaml from puppet.

The
 test does not modify the default hiera yaml file. The previous default file would create a lookup hierarchy, so all the test did was add a data file with entries that would resolve via that hierarchy.


The new default does not specify the same hierarchy, so lookup now fails where it previously succeeded.

This is problematic because the original hiera.yaml file was never modified - which means package managers won't back it up given a new one (the hiera 5 yaml) on upgrade. If users were relying on the previous behavior their lookups will fail.

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 4:29:03 PM6/14/17
to puppe...@googlegroups.com

The layout is no longer using a Hiera 3 config that points into an environment.

well, to be fair, their original hiera 3 config didn't either - that's the default if no datadir is specified.

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 4:43:03 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza commented on CI Blocker PUP-7664

Also not sure if this is related or not, but if I rename /etc/puppetlabs/code/environments/production/hieradata to /etc/puppetlabs/code/environments/production/data, and modify /etc/puppetlabs/puppet/hiera.yaml to contain the default contents:

[root@csc104cxsh7iliv puppet]# cat hiera.yaml
---
version: 5
hierarchy:
 - name: Common
 - path: common.yaml

I get this error on lookup:

[root@csc104cxsh7iliv code]# puppet lookup --node csc104cxsh7iliv.delivery.puppetlabs.net --explain classes
Error: Could not run: Lookup of key 'lookup_options' failed: The Lookup Configuration at '/etc/puppetlabs/puppet/hiera.yaml' has wrong type, entry 'hierarchy' index 1 expects a value for key 'name'

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 4:56:03 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza commented on CI Blocker PUP-7664

I'm not sure if this is an acceptable user experience on upgrade.

One option is to rename the new default hiera 5 format files to something else, ie /etc/puppetlabs/puppet/hiera.yaml.new, so that users with an existing /etc/puppetlabs/puppet/hiera.yaml won't get it overwritten if they're relying on it, ie via /etc/puppetlabs/code/environments/hieradata/common.yaml.

Or was this plan intentional, ie we know there's a risk of breaking some installs on upgrade, but these folks need to move to hiera 5 so puppet 5 is the time to do it?

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 5:00:03 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza commented on CI Blocker PUP-7664

John O'Connor it doesn't look like your PR to puppet-agent https://github.com/puppetlabs/puppet-agent/pull/1078/files will handle this case (ie a default /etc/puppetlabs/puppet/hiera.yaml with a /etc/puppetlabs/code/environments/production/hieradata/common.yaml file using it?). Can you confirm?

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 5:00:04 PM6/14/17
to puppe...@googlegroups.com

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 5:01:03 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza updated an issue
Change By: Moses Mendoza
Method Found: Needs Assessment
CI Pipeline/s: platform puppetserver
Issue Type: CI Blocker Bug

Thomas Hallgren (JIRA)

unread,
Jun 14, 2017, 5:12:02 PM6/14/17
to puppe...@googlegroups.com
Thomas Hallgren commented on Bug PUP-7664
 
Re: "Function lookup() did not find a value for the name 'classes' on node"

Please note that /etc/puppetlabs/puppet/hiera.yaml isn't related to anything inside any environment. It's for global data. You'll need a /etc/puppetlabs/code/environments/production/hiera.yaml to appoint files in /etc/puppetlabs/code/environments/production/data

Moses Mendoza (JIRA)

unread,
Jun 14, 2017, 5:20:03 PM6/14/17
to puppe...@googlegroups.com
Moses Mendoza commented on Bug PUP-7664

Ok - per comment in PA-1139, we are expecting on upgrades not to overwrite an existing /etc/puppetlabs/puppet/hiera.yaml file. There is an existing PR up https://github.com/puppetlabs/puppet-agent/pull/1078 which can be augmented to ensure this happens, which would resolve the issue for upgraders.

John O'Connor (JIRA)

unread,
Jun 15, 2017, 9:01:30 AM6/15/17
to puppe...@googlegroups.com
John O'Connor commented on Bug PUP-7664

Moses Mendoza Do we need to account for /etc/puppetlabs/code/environments/production/hieradata/common.yaml ?

Kenn Hussey (JIRA)

unread,
Jun 15, 2017, 9:13:03 AM6/15/17
to puppe...@googlegroups.com

John O'Connor (JIRA)

unread,
Jun 15, 2017, 9:32:02 AM6/15/17
to puppe...@googlegroups.com

John O'Connor (JIRA)

unread,
Jun 15, 2017, 9:33:02 AM6/15/17
to puppe...@googlegroups.com
John O'Connor updated an issue

Pulling in as breaking Puppet Server tests.

Change By: John O'Connor
Sprint: Agent 2017-06-28

Moses Mendoza (JIRA)

unread,
Jun 15, 2017, 11:08:02 AM6/15/17
to puppe...@googlegroups.com

Kenn Hussey (JIRA)

unread,
Jun 15, 2017, 12:44:04 PM6/15/17
to puppe...@googlegroups.com

Henrik Lindberg (JIRA)

unread,
Jun 15, 2017, 7:18:02 PM6/15/17
to puppe...@googlegroups.com
Henrik Lindberg updated an issue
Change By: Henrik Lindberg
Release Notes Summary: covered by general documentation about hiera
Release Notes: Not Needed

John Duarte (JIRA)

unread,
Jun 19, 2017, 10:39:03 AM6/19/17
to puppe...@googlegroups.com
John Duarte updated an issue
Change By: John Duarte
QA Risk Assessment: Needs Assessment No Action

Nicky Kernohan (JIRA)

unread,
Apr 4, 2018, 3:38:05 AM4/4/18
to puppe...@googlegroups.com
Nicky Kernohan updated an issue
Change By: Nicky Kernohan
Somewhere in between 78e175e6 and 27fdad2 of puppet, puppet server tests have started failing.

10:26:01 p7145rmqxgo7fs9.delivery.puppetlabs.net (redhat7-64-1) 17:26:01$ curl --silent --cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem --key /etc/puppetlabs/puppet/ssl/private_keys/p7145rmqxgo7fs9.delivery.puppetlabs.net.pem --cert /etc/puppetlabs/puppet/ssl/certs/p7145rmqxgo7fs9.delivery.puppetlabs.net.pem https://p7145rmqxgo7fs9.delivery.puppetlabs.net:8140/puppet/v3/catalog/p7145rmqxgo7fs9.delivery.puppetlabs.net?environment=production | python -m json.tool
10:26:01   {
10:26:02       "issue_kind": "RUNTIME_ERROR",
10:26:02       "message": "Server Error: Function lookup() did not find a value for the name 'classes' on node p7145rmqxgo7fs9.delivery.puppetlabs.net"

10:26:02   }
10:26:02
10:26:02 p7145rmqxgo7fs9.delivery.puppetlabs.net (redhat7-64-1) executed in 1.00 seconds
10:26:02 Minitest::Assertion: FAIL: Expected catalog to contain current_code_id 3aafbd686b0f884f4519de1ebd6fdac5d2454d14..
{code}

On repro, the actual stack trace from logs is [ https://gist.github.com/MosesMendoza/4cdedf11fb92c137404a29b28d137a48 ] .


*Update*
This is the result of laying down a hiera 5 yaml file in puppet instead of the previous default hiera yaml file provided by the hiera project.

This was done in [ https://github.com/puppetlabs/puppet/commit/7178bf1850c1addc40b5cc31a29aa4add09f34a9 ] . The puppet install.rb runs after the hiera install.rb during the puppet agent build process, so the hiera.yaml from hiera is overwritten by the hiera.yaml from puppet.

The
test does not modify the default hiera yaml file. The previous default file would create a lookup hierarchy, so all the test did was add a data file with entries that would resolve via that hierarchy.

The
new default does not specify the same hierarchy, so lookup now fails where it previously succeeded.


This is problematic because the original hiera.yaml file was never modified - which means package managers won't back it up given a new one (the hiera 5 yaml) on upgrade. If users were relying on the previous behavior their lookups will fail.
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Tony Juric (Jira)

unread,
Aug 28, 2020, 2:53:03 AM8/28/20
to puppe...@googlegroups.com
Tony Juric assigned an issue to Tony Juric
Change By: Tony Juric
Assignee: John O'Connor Tony Juric
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages