date:20140610

Title: Message Title










 

 Daniele Sluijters commented on an issue


















  Re: contain causes edges with nil targets to be added to the catalog 










Henrik Lindberg Doesn't look like it. Running the code I posted earlier to reproduce this still results in:


Error: undefined method `ref' for nil:NilClass on node chell.nedap.local
Error: undefined method `ref' for nil:NilClass on node chell.nedap.local















   

 Add Comment

























 Puppet /  PUP-1983



  contain causes edges with nil targets to be added to the catalog 







 With certain manifests, interestingly enough not all of them, using contain causes nil edges to be added to the catalog.   {noformat}  class profile::apt {  contain apt  contain apt::backports  contain apt::unattended_upgrades  }  {noformat}  This causes a nil edge to appear in the catalog from {{Class\[Apt\]}} to nothing.   Using this pattern, wh...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because you

Jira (PUP-1983) contain causes edges with nil targets to be added to the catalog

Title: Message Title










 

 Daniele Sluijters updated an issue


















 Puppet /  PUP-1983



  contain causes edges with nil targets to be added to the catalog 










Change By:

 Daniele Sluijters




Affects Version/s:

 3.6.1












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-1983) contain causes edges with nil targets to be added to the catalog

Title: Message Title










 

 Daniele Sluijters updated an issue


















 Puppet /  PUP-1983



  contain causes edges with nil targets to be added to the catalog 










Change By:

 Daniele Sluijters




Assignee:

 DanieleSluijters HenrikLindberg












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-2371) Truthiness and nullness

Title: Message Title










 

 Daniele Sluijters commented on an issue


















  Re: Truthiness and nullness 










I don't think so. It was a good place to collect some information about the current state though.












   

 Add Comment

























 Puppet /  PUP-2371



  Truthiness and nullness 







 Puppet's definition of what is truly True, False or Nil is completely insane. Now that Puppet 4 has opened up I think it's a good time to fix this, once and for all.   The problem has recently hit me in Types and Providers where trying to use Boolean parameters and properties is just impossible because the RAL in a lot of places checks for truthiness ins...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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-704) PuppetDB installing postgresql is not optional

2014-06-10 Thread Aaron Hicks (JIRA)

Title: Message Title










 

 Aaron Hicks commented on an issue


















  Re: PuppetDB installing postgresql is not optional 










So you're saying I should divert from the standardised installation of the module to install the standard module.
We're talking about a fundamental separation of concerns here. The PuppetDB module installs PuppetDB, it's not the PostgreSQL module that installs PostgreSQL. Using resources (like databases, grants, roles etc.) is fine and has no impact on other modules or services (unless there are other instances of the resource with exactly the same name). Declaring classes prohibits declaring that class in different ways if that class is overloaded (say when a database server provides services for several databases), unless you're prepared to expose and pass through all that classes parameters (like the PuppetDB module does for listen_addresses).












   

 Add Comment

























 PuppetDB /  PDB-704



  PuppetDB installing postgresql is not optional 







 The puppetlabs-puppetdb module installs PostgreSQL, and this is not optional.   This means it is not possible to install postgresql separately with a tuned configuration for your environment, or in a manner that could be reused by other services.   Either make the installation of the PuppetDB optiona via a parameter, or remove it completely.   By param...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)

Jira (PDB-704) PuppetDB installing postgresql is not optional

Title: Message Title










 

 Kenneth Barber commented on an issue


















  Re: PuppetDB installing postgresql is not optional 










 So you're saying I should divert from the standardised installation of the module to install the standard module.
Aaron Hicks I'm saying you should divert from the standardised installation for the database element because your needs aren't standard (well at least not according to the module). So yeah, this is pretty much what I am saying.
In this case, the class for helping you install the PuppetDB 'database' is just simply a wrapper around the postgresql::server class, and then it declares a single 'postgresql::server::db' resource to setup the database/user/grant. So, because you've want to declare postgresql::server outside of this module, I'm simply suggesting adding something like this to your manifest to complete the same job as 'puppetdb' wrapper:



  postgresql::server::db { 'puppetdb':
user = 'puppetdb',
password = 'puppetdb',
grant= 'all',
  }



Its simply a case that we would be remiss to try and replicate every single item and possible configuration for PostgreSQL in the PuppetDB module, the work of mapping such a thing is simply a waste and you'll never keep up with the parity match (unless you do horrible things). So in my honest opinion, if you stretch beyond the basic needs of the puppetdb way of doing it, I say go directly to the PostgreSQL module to do the work. And this is perfectly fine IMHO.
 We're talking about a fundamental separation of concerns here.
Okay.
 The PuppetDB module installs PuppetDB, it's not the PostgreSQL module that installs PostgreSQL.
That sentence doesn't make sense. In the case of the PuppetDB module, it does use the postgresql module to install postgresql. Even in your example you use the postgresql module to install postgresql. Perhaps I'm not understanding your message here.
 Using resources (like databases, grants, roles etc.) is fine and has no impact on other modules or services (unless there are other instances of the resource with exactly the same name). Declaring classes prohibits declaring that class in different ways if that class is overloaded (say when a database server provides services for several databases), unless you're prepared to expose and pass through all that classes parameters (like the PuppetDB module does for listen_addresses).
Yes, everything you have said is true. I'm sensing you're trying to express a puritist concern here, but I'm not getting it . I'm trying to help you with your issue, but I think you want to debate the architecture more than any bug perhaps?












   

 Add Comment

Jira (PUP-2746) new parameter allow_virtual

2014-06-10 Thread Curtis Ruck (JIRA)

Title: Message Title










 

 Curtis Ruck created an issue


















 Puppet /  PUP-2746



  new parameter allow_virtual 










Issue Type:

  Bug




Affects Versions:


 3.6.0




Assignee:

 Kylo Ginsberg




Components:


 Client, QA, Server




Created:


 10/Jun/14 5:55 AM




Priority:

  Normal




Reporter:

 Curtis Ruck










So, this whole allow_virtual new parameter has been extremely frustrating. 
We use puppet to manage package updates, i.e. package {'puppet': ensure=latest}
Therefore, we added Package {allow_virtual=false}
 in order to remove the extraneous warning, of which because its in RED, our customers think something broke.
Then, since not all of the puppet agent's were running 3.6.x at that time, they broke because allow_virtual is a new parameter, of which your changing the default to, when it didn't exist.
The entire way this allow_virtual was handled has been a severe pain. It would of been much nicer if you had added the default allow_virtual=false to maintain existing functionality, since according to semantic versioning you can add features but not break existing environments.
Then in Puppet 4.x you change the default of allow_virtual=true when your customers are expecting breaking changes.
Thank you for

Jira (PUP-1125) Exec checks should be turned into metaparameters

2014-06-10 Thread John Bollinger (JIRA)

Title: Message Title

John Bollinger commented on an issue

Re: Exec checks should be turned into metaparameters

If at all, it would likely be most acceptable to have the metaparameters behave just like the exec parameters

Acceptable is an odd choice of words there. So far only one person in this conversation could be construed as finding any of the proposed alternatives unacceptable. And that person thinks mimicing the behavior of Exec's parameters is far and away the worst of the three alternatives.
Some of the other comments vaguely in that direction seem premised on the idea that the proposed new metaparameters would be named the same as the Exec parameters, but the names should follow from the chosen behavior, not the other way around.

That behavior can be approximated by chaining an actual exec before the resource in question note that in contrast to exec, there would be an error message for a resource that is short-circuited in this fashion there are also implications for dependent resources, because the resource in question effectively fails - from this point of view, the workaround is quite dissimilar from the exec parameter's behavior after all

Yes, and that's as it should be, whether the behavior is provided by chaining an Exec or by the proposed metaparameters. A resource must fail if its declared properties are not in sync after Puppet processes it – that's practically a definition of resource failure. On the other hand, it is a viable question whether such failures should be quiet or noisy.

Another workaround are Facts, which may not scale to the number of required checks a fact based solution also makes it more difficult to handle dependent resources

Where does that last come from? Surely a fact-based solution makes it easier to deal with dependent resources, because the result of evaluating the condition is embodied in a fact, and can therefore influence multiple resource declarations.
That goes double if one supposes that the model of Exec.onlyif will be the one chosen for this feature, for that would make it impossible ever to be confident that any given resource was in sync, at least in the sense that we use that term now, anywhere outside that resource instance's provider.

All things considered, I believe that we did find possible use cases for the metaparameters. Workarounds exist, but are rather clunky. Also, I don't believe that a workaround exists is an adequate reason to deny the implementation of a feature (see nagios config permissions for an example of us walking into that trap before).

It was never in doubt that there were use cases; the feature would not have been requested otherwise. The main reason for considering use cases is to evaluate how best to serve those cases.
I agree that a workaround exists is not an adequate reason to deny implementation, but Puppet can do that already is an excellent reason. There is no bright line separating those.
Also, there are a host other conceivable reasons for denying implementation in general – just because it can be implemented and some people

Jira (FACT-462) Remove raring from build_defaults, it is EOL

Title: Message Title










 

 Melissa Stone updated an issue


















 Facter /  FACT-462



  Remove raring from build_defaults, it is EOL 










Change By:

 Melissa Stone




Fix Version/s:

 2.0.2












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-1983) contain causes edges with nil targets to be added to the catalog

2014-06-10 Thread Henrik Lindberg (JIRA)

Title: Message Title










 

 Henrik Lindberg commented on an issue


















  Re: contain causes edges with nil targets to be added to the catalog 










Oh, I think this is the same as PUP-121












   

 Add Comment

























 Puppet /  PUP-1983



  contain causes edges with nil targets to be added to the catalog 







 With certain manifests, interestingly enough not all of them, using contain causes nil edges to be added to the catalog.   {noformat}  class profile::apt {  contain apt  contain apt::backports  contain apt::unattended_upgrades  }  {noformat}  This causes a nil edge to appear in the catalog from {{Class\[Apt\]}} to nothing.   Using this pattern, wh...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-2426) Puppet's v2 environment listing does not display config_version and environment_timeout as well.

2014-06-10 Thread Henrik Lindberg (JIRA)

Title: Message Title










 

 Henrik Lindberg commented on an issue


















  Re: Puppet's v2 environment listing does not display config_version and environment_timeout as well. 










Added note to predocs.












   

 Add Comment

























 Puppet /  PUP-2426



  Puppet's v2 environment listing does not display config_version and environment_timeout as well. 







 We added config_version and environment_timeout settings to directory environment environment.conf. Puppet's v2 environments listing needs to show these environment parameters as well. (lib/puppet/network/http/api/v2/environments.rb)   Will also need to update the API docs for v2.0/environments















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (FACT-429) facter fails on smartos

Title: Message Title










 

 Melissa Stone updated an issue


















 Facter /  FACT-429



  facter fails on smartos 










Change By:

 Melissa Stone




Fix Version/s:

 2.0.2




Fix Version/s:

 2.1












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (FACT-465) LinuxMint support is missing in facter stable/facter-2

Title: Message Title










 

 Melissa Stone updated an issue


















 Facter /  FACT-465



  LinuxMint support is missing in facter stable/facter-2 










Change By:

 Melissa Stone




Fix Version/s:

 2.0.2




Fix Version/s:

 2.1












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (FACT-375) Acceptance test Facter from packages

Title: Message Title










 

 Melissa Stone updated an issue


















 Facter /  FACT-375



  Acceptance test Facter from packages 










Change By:

 Melissa Stone




Fix Version/s:

 2.0.2




Fix Version/s:

 2.1












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-2738) Investigate FFI Memory Pressure / Deterministically Release FFI MemoryPointer

2014-06-10 Thread Ethan Brown (JIRA)

Title: Message Title










 

 Ethan Brown commented on an issue


















  Re: Investigate FFI Memory Pressure / Deterministically Release FFI MemoryPointer 










Let's merge what's here so far.. it's good to go.
Then revisit once security is wrapped. In my local tests, the memory pressure issues seem to be less prevalent. It would be nice to push these changes through CI / acceptance to see what happens.












   

 Add Comment

























 Puppet /  PUP-2738



  Investigate FFI Memory Pressure / Deterministically Release FFI MemoryPointer 







 As of the merge for PUP-2657, we've noticed some intermittent test failures (in both CI and locally) in semi-random locations. The merge commit is as follows:   https://github.com/puppetlabs/puppet/commit/d38153bd712167e2777bdd4c63d37e2e8d1cdb39   The commit itself has been reviewed and it doesn't seem to have issues itself, but it's likely it's trigge...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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.

Jira (PUP-1983) contain causes edges with nil targets to be added to the catalog

Title: Message Title










 

 Daniele Sluijters commented on an issue


















  Re: contain causes edges with nil targets to be added to the catalog 










Do you have any idea why the second example works (as in both notices are fired) but we still get the `ref` for nil:NilClass? That seems contradictory to me.












   

 Add Comment

























 Puppet /  PUP-1983



  contain causes edges with nil targets to be added to the catalog 







 With certain manifests, interestingly enough not all of them, using contain causes nil edges to be added to the catalog.   {noformat}  class profile::apt {  contain apt  contain apt::backports  contain apt::unattended_upgrades  }  {noformat}  This causes a nil edge to appear in the catalog from {{Class\[Apt\]}} to nothing.   Using this pattern, wh...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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

Jira (PUP-2747) support multiple profilers

2014-06-10 Thread Christopher Price (JIRA)

Title: Message Title










 

 Christopher Price created an issue


















 Puppet /  PUP-2747



  support multiple profilers 










Issue Type:

  Task




Assignee:

 Aaron Armstrong




Components:


 PE




Created:


 10/Jun/14 9:26 AM




Priority:

  Normal




Reporter:

 Christopher Price










The current implementation of the profiling system uses a single setter method to assign/remove the active profiler. This means that it's not safe to manipulate the active profiler in new code unless you know for sure that it will not be manipulated by any other parts of the code that will be executed during the run. It also means that you can only have a single kind of profiler active at a given time.
For callers who would like to use the puppet code as a library, it'd be much nicer (and safer) for them to be able to register and remove their own profiler without having knowledge of how the rest of the system might or not be handling profiling.
This could be accomplished pretty easily by simply changing the existing profiling code to store an array or map of active profilers, rather than a single instance. The API can change to use an `add`/`remove` syntax, rather than a setter. Then anyone who wishes to do so can add and remove a unique profiler instance at the appropriate times, without stepping on the toes of any other code that is using the profiling system.

Jira (PUP-1112) Puppet Packages should be built to support Ruby 1.9 from Software Collections.

2014-06-10 Thread Paul Gomersbach (JIRA)

Title: Message Title










 

 Paul Gomersbach commented on an issue


















  Re: Puppet Packages should be built to support Ruby 1.9 from Software Collections. 










A good reason is a issue as this: http://projects.theforeman.org/issues/4244 












   

 Add Comment

























 Puppet /  PUP-1112



  Puppet Packages should be built to support Ruby 1.9 from Software Collections. 







 Many RHEL/CentOS users wish to move to Ruby 1.9 but without having to roll their own environment and repackage all Puppet packages.   The Fedora Software Collections gives us this capability and I would like to request that a set of packages be rolled to support Ruby from SC.   https://fedorahosted.org/SoftwareCollections/















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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-175) Configurable `puppetdb.conf` location

Title: Message Title

Kenneth Barber commented on an issue

Re: Configurable `puppetdb.conf` location

Henrik Lindberg I get the impression this request has many angles and not only that, probably a feature-set like this would have a few consumers (not just us, NC is another perfect example).
Perhaps I should just link this to a more encompassing PUP request to at least get the ball rolling. Can you think of a ticket that might already cover some of this need? Or any other consumers needing such a change? If not I can go looking myself for an existing ticket (there has to be one, surely).
For immediate needs Erik Daln ... I'm really failing to see even half-decent dodgy work-around to this problem, beyond the already suggested 'just have a confdir for each section' idea, which seems like it would break a lot of other stuff . Dodgy patches and out-of-band ways of doing this might work ... like plucking environment variables but man thats a nasty slope to slip down.

Add Comment

PuppetDB / PDB-175

Configurable `puppetdb.conf` location

Right now, `Puppet::Util::Puppetdb::Config.load` accepts a `config_file` argument, but (as far as I can tell) that method is only called from `Puppet::Util::Puppetdb.config` and no argument is passed. I'm insufficiently familiar with terminus stuff to make any suggestions of _how_ to do this, but in my masterless Puppet setup, I'd very much like to be ...

This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)

Jira (PUP-2650) 3.6.1 issues warning message for deprecation

Title: Message Title










 

 Adrien Thebo commented on an issue


















  Re: 3.6.1 issues warning message for deprecation 










Jo Rhett could you lay out some solutions for this problem that would work for your environment? Would finer grained disable_warnings help? Alternately, would it help if the log level for deprecation warnings could be tuned so deprecation warnings would be logged at `info` or `debug` instead of `warn`? Is the problem the fact that we're emitting a log message, or is the problem mainly due to these warnings showing up in the reports? On other words, how can we surface these issues in a manner that's user friendly and non-obtrusive, but still visible?












   

 Add Comment

























 Puppet /  PUP-2650



  3.6.1 issues warning message for deprecation 







 Message is issued from agent runs at the warning level for a deprecation message.   Warning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false. (at /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:816:in...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received

Jira (PUP-2423) Filebucket server should warn, not fail, if checksum type is not supported

Title: Message Title










 

 Adrien Thebo updated an issue


















 Puppet /  PUP-2423



  Filebucket server should warn, not fail, if checksum type is not supported 










Change By:

 Adrien Thebo




Component/s:

 Trivial












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-2423) Filebucket server should warn, not fail, if checksum type is not supported

Title: Message Title










 

 Adrien Thebo updated an issue


















 Puppet /  PUP-2423



  Filebucket server should warn, not fail, if checksum type is not supported 










Change By:

 Adrien Thebo




Story Points:

 1 3












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 (PUP-2423) Filebucket server should warn, not fail, if checksum type is not supported

Title: Message Title










 

 Adrien Thebo commented on an issue


















  Re: Filebucket server should warn, not fail, if checksum type is not supported 










This is more involved than may look on the surface because of how the filebucket code uses `HEAD` to determine if a given file needs to be filebucketed. In addition when this is fixed, if a Puppet agent and Master have mismatched digest algorithm files then file resources using `source` are no longer idempotent.












   

 Add Comment

























 Puppet /  PUP-2423



  Filebucket server should warn, not fail, if checksum type is not supported 







 PUP-1840 allows users to specify the digest algorithm to use for file bucketing and the file checksum parameter. However, if you reconfigure the master to use SHA256:   {noformat}  [main]  digest_algorithm=sha256  {noformat}   Then it will reject file bucket requests from agents that haven't switched over:   {noformat}  # puppet agent -td  ...  Error: ...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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

Jira (PUP-2748) require = Exec does not work

2014-06-10 Thread c sights (JIRA)

Title: Message Title










 

 c sights created an issue


















 Puppet /  PUP-2748



  require = Exec does not work 










Issue Type:

  Bug




Affects Versions:


 3.5.1




Assignee:


 Unassigned




Created:


 10/Jun/14 10:05 AM




Environment:


Linux




Priority:

  Normal




Reporter:

 c sights




Original Estimate:


0 minutes




Remaining Estimate:


0 minutes










Puppet 3.5.1 resources types File and Notify cannot successfully require an Exec. The File or Notified are applied no matter whether the Exec is applied or not:
 exec  { test : path = /bin:/sbin:/usr/bin:/usr/sbin, command = /bin/true, _onlyif_ = test -e /etc/, }
 notify  { test executed : require = Exec[test], }
Produces output:Info: Applying configuration

Jira (PDB-561) Rename name to certname in nodes endpoint

Title: Message Title










 

 Kenneth Barber commented on an issue


















  Re: Rename name to certname in nodes endpoint 










Ryan Senior and Erik Daln I believe this was fixed in this pull request, by this line change here: https://github.com/puppetlabs/puppetdb/pull/982/files#diff-86460443ce1db2bf4cdc26d9870e828bR49
So this is done for v4 and will be shipped in 'next' (2.1.0 at this point).












   

 Add Comment

























 PuppetDB /  PDB-561



  Rename name to certname in nodes endpoint 







 The nodes endpoint constantly need to be special cased when constructing queries as the certname is called name there instead. This should change for the next API version.















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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-561) Rename name to certname in nodes endpoint

Title: Message Title










 

 Kenneth Barber updated an issue


















 PuppetDB /  PDB-561



  Rename name to certname in nodes endpoint 










Change By:

 Kenneth Barber




Fix Version/s:

 2.1.0












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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-645) API Inconsistences