date:20141114

Jira (PUP-3336) Puppet defaults.rb doesn't split :libdir if multiple paths provided

2014-11-14 Thread Josh Cooper (JIRA)

Title: Message Title

Josh Cooper commented on PUP-3336

Re: Puppet defaults.rb doesn't split :libdir if multiple paths provided

The ability to specify multiple directories in :libdir was added in f9e05a80, but I don't believe it ever worked correctly. First, in that version of puppet, it would infer the type of setting based on its value. Anything looking like a file path was assumed to be a FileSetting. And any FileSetting whose value starts with '/' was assumed to be a directory. If you ever attempted to "use" that setting (in the Puppet sense), it would create the directory by applying the settings catalog. If the libdir contained multiple directories, then it would fail:

Error: Cannot create /Users/josh/work/modules/a/lib:~/work/modules/b/lib; parent directory /Users/josh/work/modules/a/lib:~/work/modules/b does not exist

This is the same error reported in http://projects.puppetlabs.com/issues/3094, which was supposed to be fixed by f9e05a80.
Also the puppet-dev discussion points out the problems with allowing libdir to contain multiple values. https://groups.google.com/d/topic/puppet-dev/_nMvueR3ESc/discussion. Basically, it's trying to load code from multiple directories, but we need to be able to pluginsync code into one of those directories, so which one do we pick? This is also discussed in http://projects.puppetlabs.com/issues/3464#note-2
We have a couple different options.

We could allow :libdir to contain multiple directories. The setting type would need to be changed from :directory to :path. Note that puppet will create directory settings, but not path settings. This might break code that assumes the libdir exists. We would also need to fix the code in puppet that assumes its a single directory, e.g. augeas. We would also have to update the plugindest setting, since it would need to default to one component of the :libdir.

We could continue enforcing the requirement that libdir is a single directory. The fact that the autoloader accepts multiple directories is something that only works in testing, but not when actually running puppet. To allow modules to load code from other modules during testing, we could modify puppet's test helper (lib/puppet/test/helper.rb) to modify the LOAD_PATH using something like Puppet::Node::Environment#each_plugin_directory. I would prefer to keep that logic in puppet and not puppetlabs_spec_helper so that we don't have versioning issues between puppet and puppetlabs_spec_helper.

I would prefer to go with option 2.
/cc Henrik LindbergJoshua Partlow

Jira (PUP-3388) Issue Creating Multiple Mirrors in Zpool Resource

2014-11-14 Thread Josh Cooper (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Josh Cooper assigned an issue to Josh Cooper 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-3388 
 
 
 
  Issue Creating Multiple Mirrors in Zpool Resource  
 
 
 
 
 
 
 
 
 

Change By:
 
 Josh Cooper 
 
 
 

Assignee:
 
 Josh Cooper 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PDB-1029) PR (1156): (PUP-3512) Use new Profiler API - fpringvaldsen

2014-11-14 Thread gepetto-bot (JIRA)

Title: Message Title

gepetto-bot commented on PDB-1029

Re: PR (1156): (PUP-3512) Use new Profiler API - fpringvaldsen

kbarber commented:
@fpringvaldsen this will need a stable branch target. Feel free to fix these comments from @cprice404 first before rebasing.
Can I ask you both a question, what does this hierarchy that is a metric_id mean? And what is its goal?
In the Ruby puppet profiler, it has this capability to enumerate where in the stack tree the profile is being called from, looking at this new one: https://github.com/puppetlabs/puppet-server/blob/f833bf81498400517c7e1fa1eea1d7161b6c03cb/src/java/com/puppetlabs/puppetserver/LoggingPuppetProfiler.java, I can't see how it does it here.
I guess what I'm trying to say is, are we still showing the stack level in the profile? Your request.key thing made me think about hierarchy thats all, but the previous system kind of did that automatically.

Add Comment

This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e)

--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

48 matches

Mail list logo