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

Bug #12115

'Local' file bucket behavior doesn't match documentation

Added by Josh Cooper almost 3 years ago. Updated about 2 years ago.

Status:Needs DecisionStart date:01/24/2012
Priority:NormalDue date:
Assignee:J.D. Welch% Done:

0%

Category:fileserving
Target version:-
Affected Puppet version:2.7.9 Branch:
Keywords:ux

We've Moved!

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

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

The usage for command puppet filebucket backup says that, “Alternatively, you can use your local file bucket by specifying ‘—local’. However, it actually stores the file in $vardir/bucket:

$ rm -rf ~/.puppet
$ puppet filebucket backup -l /dev/null
/dev/null: d41d8cd98f00b204e9800998ecf8427e
$ find ~/.puppet/var/*bucket
/Users/josh/.puppet/var/bucket/d/4/1/d/8/c/d/9/d41d8cd98f00b204e9800998ecf8427e

Note there’s no var/clientbucket. I would have expected it to write to $vardir/clientbucket, since the documentation in defaults.rb says, “:clientbucketdir => { :desc => Where FileBucket files are stored locally.}”

The file face behaves the same way:

$ puppet file store /dev/null
Users/josh/.puppet/var/bucket/d/4/1/d/8/c/d/9/d41d8cd98f00b204e9800998ecf8427e

It seems wrong that the “local” file bucket for an agent would be $vardir/bucket, though it might make sense in master run mode, I’m not sure.

This issue was discovered while researching the acceptance test for #6541. It was trying to preload the local bucket using the puppet filebucket backup -l /dev/null command, which was writing the $vardir/bucket. Then later the test was trying to retrieve the file using a file resource with content => ‘{md5}d41d8cd98f00b204e9800998ecf8427e’ in puppet apply, but failing because puppet was looking in $vardir/clientbucket.

I’m honestly not sure what the right behavior is supposed to be. It seems strange that an agent would have two file buckets. But perhaps that’s because the test was using puppet apply and not puppet agent --onetime. Or perhaps the behavior needs to be better documented about what ‘local’ means in these different contexts.


Related issues

Related to Puppet - Bug #6541: File type truncates target when filebucket can not retrie... Closed 03/01/2011
Related to Puppet - Feature #17095: Improve puppet's command line interaction Investigating

History

#1 Updated by Anonymous almost 3 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee changed from Anonymous to Anonymous

Randall, this is all about the user interaction with these tools. As far as I can tell they have very little purpose, and what there is actually matters only in terms of extracting content from the file bucket with an already known MD5.

Do you want to put one of your team on figuring out what they should do? Otherwise I am tempted to say that any feature other than that one, very specific, use case should be turned off until we find an actual use-case for them.

#2 Updated by Anonymous almost 3 years ago

Daniel Pittman wrote:

Otherwise I am tempted to say that any feature other than that one, very specific, use case should be turned off until we find an actual use-case for them.

I agree. This seems like configurability looking for a problem.

#3 Updated by Anonymous about 2 years ago

  • Assignee changed from Anonymous to J.D. Welch

#4 Updated by J.D. Welch about 2 years ago

  • Keywords changed from file bucket to file bucket backlog

#5 Updated by J.D. Welch about 2 years ago

  • Keywords changed from file bucket backlog to backlog

#6 Updated by eric sorenson about 2 years ago

  • Keywords changed from backlog to ux

Also available in: Atom PDF