The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #6810

File 'fail' became a lot more fatal in 2.6.0

Added by eric sorenson about 3 years ago. Updated about 1 year ago.

Status:ClosedStart date:03/22/2011
Priority:NormalDue date:
Assignee:Charlie Sharpsteen% Done:

0%

Category:file
Target version:-
Affected Puppet version:2.6.0 Branch:
Keywords: customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

In testing 2.6.6, we found that missing source directories in a recurse=>remote file copy cause puppetd to exit immediately, whereas earlier versions just cause that particular resource to fail but continue with the rest of the catalog. Did failures become intentionally more fatal in 2.6.6? I can work to bisect when this started happening but wondered if it was a known issue. Stack trace/output:

/usr/lib/ruby/site_ruby/1.8/puppet/parameter.rb:171:in `fail'/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:156:in `init_metadata'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:106:in `cached_value'/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:98:in `cached_value'/usr/lib/ruby/site_ruby/1.8/puppet/util/cacher.rb:48:in `metadata'/usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb:109:in `copy_source_values'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:622:in `retrieve'/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:703:in `retrieve_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1874:in `to_trans'
/usr/lib/ruby/site_ruby/1.8/puppet/type/file.rb:691:in `to_trans'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:1899:in `to_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/type.rb:203:in `uniqueness_key'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:83:in `add_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:72:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:72:in `add_resource'/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:561:in `to_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:531:in `each'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:468:in `to_ral'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:113:in `convert_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:108:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:139:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run'
/usr/sbin/puppetd:4
err: Could not run Puppet configuration client: Could not retrieve information from source(s) puppet:///async/users/admins/vkoleti/ssh at /etc/puppet/modules/homes/manifests/init.pp:28

Related issues

Related to Puppet - Feature #6911: Flexible, deterministic, unguessable application order Closed 03/30/2011

History

#1 Updated by eric sorenson about 3 years ago

OK, actually 2.6.4 behaves the same.

#2 Updated by eric sorenson about 3 years ago

Sorry, this goes back to 2.6.0. So the title is inaccurate. Is this an intentional change, then?

#3 Updated by Ben Hughes about 3 years ago

  • Category set to file
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten
  • Affected Puppet version set to 2.6.0

This is for the following situation:

file{
  "/tmp/foo":
    ensure  => directory,
    source  =>  "puppet:///files/i/dont/exist",
    recurse => remote,
}

(where say, the source is populated by a variable or whatever).

Is this either on purpose or a regression?

If it is on purpose, can we make it fail better? And document it somewhere.

#4 Updated by Nigel Kersten about 3 years ago

  • Status changed from Needs Decision to Needs More Information

Is it only when recursing? Or does this happen when any file resource has an non-existent source?

#5 Updated by Nigel Kersten about 3 years ago

  • Status changed from Needs More Information to Accepted
  • Assignee deleted (Nigel Kersten)

Reproducible case:


file { "/tmp/foobar":
  ensure  => directory,
  source  => "puppet:///modules/foo/barba",
  recurse => true,
}

file { "/tmp/later":
  ensure  => file,
  content => "laterfile",
}

Fails to apply the /tmp/later resource if you have recurse => remote set.

#6 Updated by Nigel Kersten about 3 years ago

  • Target version set to 2.6.x

#7 Updated by Nigel Kersten about 3 years ago

  • Subject changed from File 'fail' became a lot more fatal in 2.6.6 to File 'fail' became a lot more fatal in 2.6.0

#8 Updated by James Turnbull over 2 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Nigel Kersten

Nigel – what’s your view here on the desired outcome?

#9 Updated by Nigel Kersten over 2 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)

The resource itself (and dependencies) should fail, but the rest of the catalog should be applied. Eric has it right.

#10 Updated by Michael Stahnke about 2 years ago

  • Target version changed from 2.6.x to 2.7.x

2.6.x is closed. Moving to 2.7.x

#11 Updated by Andrew Parker over 1 year ago

  • Target version deleted (2.7.x)

#12 Updated by Andrew Parker over 1 year ago

As the 2.7.x line is winding down, I am removing the target at 2.7.x from tickets in the system. The 2.7 line should only receive fixes for major problems (crashes, for instance) or security problems.

#13 Updated by Charlie Sharpsteen about 1 year ago

  • Assignee set to Charlie Sharpsteen

#14 Updated by eric sorenson about 1 year ago

Charlie can you try to repro under 3.1/master?

#15 Updated by Charlie Sharpsteen about 1 year ago

Could not reproduce using 3.1.1, 2.7.21 or, strangely enough, 2.6.6. The following manifest always resulted in the creation of /tmp/later:

file { "/tmp/foobar":
  ensure  => directory,
  source  => "puppet:///modules/foo/barba",
  recurse => remote,
}

file { "/tmp/later":
  ensure  => file,
  content => "laterfile",
}

#16 Updated by Charlie Sharpsteen about 1 year ago

  • Keywords set to customer

#18 Updated by Charlie Sharpsteen about 1 year ago

  • Status changed from Accepted to Closed

Closing as “cannot reproduce”.

Also available in: Atom PDF