Jira (PUP-10969) The yum provider gets confused by virtual provides
Title: Message Title
John Bollinger created an issue
Puppet / PUP-10969
The yum provider gets confused by virtual provides
Issue Type:
Bug
Affects Versions:
PUP 6.17.0, PUP 7.5.0
Assignee:
Unassigned
Components:
Types and Providers
Created:
2021/03/18 11:51 AM
Priority:
Normal
Reporter:
John Bollinger
Puppet Version: 7.5 Puppet Server Version: 7.1.0 OS Name/Version: CentOS 7.8 Puppet does not install packages to update virtual provides of other packages. This appears to be approximately the opposite of the situation described in PUP-10798. Desired Behavior: Puppet should ensure that the latest available version of the requested package is installed. Actual Behavior: Puppet denies that there is an update available. In the specific case where I hit this issue, the target nodes have package python-pandas-0.17.1-1.el7.x86_64 installed, and it declares a virtual provide for python2-pandas, version 0.17.1-1.el7. In my local repository, I have a package python2-pandas-0.24.2-1.el7.myorg.x86_64, which I want Puppet to install. Under those circumstances, when I then ask yum directly to either install or update package python2-pandas, it offers the version 0.24.2 package (and because of obsoletes processing, this replaces the other). If I try to have Puppet do the same, however, it claims that the latest available version is already installed. The Puppet resource I am applying is
package { 'python2-pandas': ensure => 'latest' }
Jira (PDB-4997) The puppetlabs-puppetdb module has an undocumented dependency on camptocamp-systemd
Title: Message Title John Bollinger created an issue PuppetDB / PDB-4997 The puppetlabs-puppetdb module has an undocumented dependency on camptocamp-systemd Issue Type: Bug Affects Versions: PDB module-7.7.1 Assignee: Unassigned Components: PuppetDB Created: 2020/12/22 1:22 PM Priority: Normal Reporter: John Bollinger The puppetdb::server class of puppetlabs-puppetdb module conditionally declares a resource Systemd::Unit_file['puppetdb-dlo-cleanup.service'], but no 'systemd' module is declared among the module's dependencies in its metadata.json file. My best guess is that the wanted module is camptocamp-systemd, since that is "approved" and popular, and it provides a resource type of that name. There is no puppetlabs-systemd on the Forge. Add Comment
Jira (PDB-4997) The puppetlabs-puppetdb module has an undocumented dependency on camptocamp-systemd
Title: Message Title
John Bollinger updated an issue
PuppetDB / PDB-4997
The puppetlabs-puppetdb module has an undocumented dependency on camptocamp-systemd
Change By:
John Bollinger
The {{puppetdb::server}} class of module puppetlabs-puppetdb module conditionally declares a resource {{Systemd::Unit_file['puppetdb-dlo-cleanup.service']}}, but no 'systemd' module is declared among the module's dependencies in its metadata.json file. My best guess is that the wanted module is camptocamp-systemd, since that is "approved" and popular, and it provides a resource type of that name. There is no puppetlabs-systemd on the Forge.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
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 view this discussion on the web visit
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title John Bollinger commented on PUP-10018 Re: The module tool won't solve some dependencies without --force or --ignore-dependencies Thanks for your comments, Josh Cooper. I'm a bit distanced from this issue now, six months later, but I know that I did in the end get the module updates performed. I forget whether I used --force for that, but I suspect that I instead uninstalled several modules and then installed new versions with their newer dependencies. Of course, the whole point of this issue is that neither --force nor --ignore-dependencies should be required in cases such as the one presented. Also, "the PMT doesn't know to upgrade dependencies at the same time" does seem to sum up the problem, but my vague and possibly mistaken recollection is that it's not completely accurate. That is, I think I do see it perform multiple upgrades in the same run sometimes, just not when any of the upgrades crosses a major-version-number threshold. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.324663.1568391367000.12211.1584105120176%40Atlassian.JIRA.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title John Bollinger commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax It sounds like there is some consensus forming. There is surely some diversity in how we each imagine the details, but we all seem to agree that a standalone query would be a desirable thing. At least, that's what I would characterize a collector that does not automatically realize to be. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.191187.1494891335000.4461.1580306462085%40Atlassian.JIRA.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title John Bollinger commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax The issue is when using Puppet Enterprise for example there are packages that are virtual and depending upon how you use collectors this will cause some nasty behavior That's certainly an issue, Chris Denneen, but the issue we're discussing here is broader. How does one propose to continue to use Collectors (or PQL) to allow for the desired behavior that Yum gets updated before yumrepo which are all applied before all other packages. With current PE alone, one would need to write a more selective collector. Either additional resource titles could be excluded specifically, or perhaps tags could be brought to bear to exclude the Puppet Enterprise packages. If one is willing to engage third-party modules, then it looks like Ben's Manifold module can stand in for a collector in that particular case and many similar ones. As I already commented, the broader issue revolves around the fact that collectors serve dual purposes. Way back in Puppet 2, they served only to realize virtual resources and collect exported ones. They retain those functions today, but since P3 they also serve to group resources as operands for the chain operators and for parameter overrides. Presently, there is no way to obtain either of the latter two collector behaviors without the first, but there could be in Puppet 8 (or maybe even in Puppet 7?). I already suggested one way that could be implemented, but there are certainly others, including alternatives along the lines of Ben's module. The first iteration of this discussion established that there was still strong support for exported and virtual resources at that time. Perhaps that has since waned, but I, at least, still want to keep them. On the other hand, the specifics of current collector syntax and semantics are much more open to consideration, and from my perspective, that's where PQL, Datalog, Manifold, etc. could come into the picture. Some of those can already be used to address parts of the problem. Maybe PE should avoid the use of Virtual Resources? But what's to stop Datadog, Sensu, etc vendors from doing the same. Whether PE or anyone else should stop using virtual resources is a separate question. The specific problem Ben brought up would no longer manifest if PE did so, but that would not address the larger issue.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title John Bollinger commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax The exported resources and collection use cases seems to be all solved by PQL and regular logic - do you agree? I'm not sure I do. In the first place, it's not clear to me how you have in mind to use PQL. Nothing provided by core Puppet is adequately replaced by anything other than another core Puppet feature or a feature of a module supported and maintained by Puppet, Inc.. There is no core function specifically for querying puppetdb. It appears that the puppetlabs/puppetdb module provides such a function, but as far as I can tell, that function is not documented, which I take as an indication that it is not an officially supported feature of the module. But supposing that the puppetdb_query() function were a documented, supported feature of puppetlabs/puppetdb, and that that was the intended mechanism for addressing the collection of exported resources, I suspect that it does not adequately support all use cases. In particular, I do not think it properly handles cases in which a node wants to collect a resource that it exports itself. Similar would apply to any other mechanism that gathers only data that are already recorded in puppetdb. There could be other mismatches, though none spring immediately to mind. Additionally, although collector syntax is a bit arcane, it at least feels relatively well integrated into the language. PQL is at least as arcane as collector syntax, but passing PQL strings to a function and then dealing with the resulting raw hash is nowhere near as integrated. Powerful, yes. Flexible, yes. Integrated, no. For virtual resources and overrides use cases the replacement is less obvious. I think it may require logic programming in the vein of Datalog / OPA. Which could be applied in a catalog post processing step. A difficulty is how to express those in the Puppet Language in a natural way. I'm not really up on Datalog or OPA, but I think I see why the former, at least, comes to mind. Certainly, replacing collector-based syntax with a more fully-featured declarative language can be expected to provide more flexibility, albeit at the cost of making the Puppet language more complex and less cohesive. Order-independence such as Datalog in particular provides would be well suited to Puppet use cases, too, if indeed Puppet could provide such a thing, but I doubt it can do, given that some of the use cases of interest (i.e. overriding) involve modifying the data set to which the language applies. Overall, it sure would be nice to have a consistent way to select resources from among those known / knowable to the catalog builder, instead of having to use separate mechanisms for exported and virtual resources. Collectors very nearly provide this. PQL could likely be extended to provide it, but it does not currently do so. Some new thing certainly could do so, and should do so if one is made.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title John Bollinger commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax Quoting myself: there are certainly aspects of the legacy system that would bear improvement. In particular, separating the diverse functions served by collectors from each other springs immediately to mind The error scenario you describe, Ben Ford, arises in part from no such separation having been performed, so that collectors still perform multiple largely unrelated functions. The manifold module's capabilities look interesting, but they don't solve that problem themselves. Supposing that you recognize that, I guess you are suggesting that manifold, or something substantially similar, be incorporated into core puppet in conjunction with collectors being made unacceptable operands for the chain operators. I think that would be the wrong direction. I would rather see collectors continue to work with the chain operators and for resource parameter overrides, but cease to (automatically) realize virtual resources or collect external resources, even though the latter are the original functions of the constructs. I think it makes sense for the language to have a general-purpose syntax to represent a set of resources. Collectors serve that purpose reasonably well, but manifolds not so much. It looks like manifolds do fine, within their limitations, as a stand-in for collectors for resource relationship purposes, but there remains collectors' usage for resource parameter overrides, and there may well be future applications, too. For example, once upon a time I suggested that collectors be allowed as property values, so that they could be used with the relationship metaparameters (the chain operators were introduced instead). Moreover, if we accept that a such a general-purpose group-selection syntax is sensible, then voila! it provides its own natural solution to the problem. Take away the automatic realization / collection function, and introduce instead explicit realization of resources matched by collectors. One might use the realize keyword to accomplish that, for example. Thus, one might be obliged to write ... realize Host<<| |>> realize User<| tag == 'x' |> ... instead of just ... Host<<| |>> User<| tag == 'x' |> ... if one wanted not only to collect resources that are otherwise in the catalog but also to add matching known / discoverable resources to the catalog. And one could make such realize expressions work in chain expressions and parameter override specifications, so that converting old code would just be a matter of adding one keyword in those places where it is wanted. As an aside: it does not appear that the present implementation of manifolds is as flexible as collectors with regard to specifying member resources. Collectors allow multiple criteria to be combined via logical operators, and they support search values of several non-string types, notably including resource references and undef, but it does not appear that manifolds do the same. I'm sure that's a solvable problem, but I'm uncertain what the costs of building and maintaining a solution would be.
Jira (FACT-2134) Facter should distinguish between CentOS 8 and CentOS 8 Stream
Title: Message Title John Bollinger created an issue Facter / FACT-2134 Facter should distinguish between CentOS 8 and CentOS 8 Stream Issue Type: Improvement Affects Versions: FACT 3.14.3 Assignee: Unassigned Created: 2019/11/21 7:57 AM Priority: Normal Reporter: John Bollinger CentOS 8 comes in two flavors, distinguished by name and package-release policy. Standard CentOS 8 follows the conventional RHEL versioning and release model, but CentOS Stream follows a rolling-release model that, among other things, makes minor OS version numbers less significant. Presently, Facter's OS-related facts do not distinguish between these, but they should. Behaviors that for regular CentOS 8 are conditional on minor version numbers should have different or no conditions on CentOS [8] Stream, but Facter does not presently provide a means to discriminate between them. It's unclear to me, however, exactly how Facter should present the difference. It's also unclear whether the CentOS project can be expected at any point to moot the issue, say by updating its -release files to include a distinction that Facter picks up with its existing code. Add Comment
Jira (FACT-2055) Facter fails if its working directory does not exist
Title: Message Title John Bollinger commented on FACT-2055 Re: Facter fails if its working directory does not exist I'm not sure about the "great many" Unix utilities that fail if the working directory is unlinked, James Ralston. Of the several that I selected for testing on a CentOS 7 system, the only one that failed was Bash, and even Bash ran successfully (albeit after emitting a warning) when launched as /bin/sh – both interactively and non-interactively. No other that I tested even warned. Ruby (irb), Python, and Perl were all ok. Sed was ok. /bin/cat was ok. Even /bin/ls with no arguments just silently emitted a completely empty listing. Thus, no, I don't think it's reasonable to characterize this as a Unix feature. Moreover, since I can't come up with anything that the Facter core ought to be doing that would require working-directory access, yes, it is a bug in Facter. Whether it is a bug that should be fixed is a different question. I know I can come up with scenarios where the faulty behavior is a genuine real-world problem, but it remains to be seen how contrived they would end up being. I am imagining applications in highly dynamic environments where "don't do that" is not a viable alternative. Nevertheless, I discovered this issue while trying to reproduce and characterize the inaccessible working directory case originally reported in PUP-10080. My own uses of Puppet do not ordinarily run into the unlinked working directory issue. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title John Bollinger commented on PUP-10080 Re: Exec resources fail if the working directory is inaccessible For the record, I'm fine with this resolution. I agree that my example 1 is among the cases covered by PUP-9997, but not necessarily the only such case. My example #2 has already been reassigned to FACT-2055. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.135863.1570627980142%40Atlassian.JIRA.
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title John Bollinger commented on PUP-10080 Re: Exec resources fail if the working directory is inaccessible James Ralston, I came to the same conclusion about the code change to be made, +/- explanatory code comments. That seems to be what Josh Cooper was looking at, too. I guess I can go ahead and submit the PR, and Puppet can kick it back to me if they don't want it. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.134737.1570563660128%40Atlassian.JIRA.
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title John Bollinger commented on PUP-10080 Re: Exec resources fail if the working directory is inaccessible I confirm that modifying the base Exec provider to avoid defaulting the cwd parameter resolves the Example 1 case for me. All unit tests continue to pass with that change. I would be prepared to submit a PR, but I'm not sure how to write tests that demonstrate the issue in the unpatched code, and I'm uncertain whether this ought to instead be rolled in as part of a larger patch addressing PUP-9997. Advice? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.129686.1570201260138%40Atlassian.JIRA.
Jira (PUP-9997) Puppet must not call Dir.chdir() except in a child process
Title: Message Title John Bollinger commented on PUP-9997 Re: Puppet must not call Dir.chdir() except in a child process Does this mean that the fix for PUP-5915 didn't actually resolve that issue? I'm inclined to think so, because I'm having trouble distinguishing it from PUP-10080, which I observed with Puppet 6.8.1 in a kerberized NFS home directory environment very similar to the one described here and in 5915. In any case, I agree with the prescription that Dir.chdir() should be avoided wherever possible, and performed only in a child process when it cannot be avoided. I suspect that making Execs avoid unnecessarily changing the working directory (i.e. when no cwd parameter is specified) will resolve 10080. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.323575.156763800.129606.1570196040299%40Atlassian.JIRA.
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title John Bollinger commented on PUP-10080 Re: Exec resources fail if the working directory is inaccessible I agree that this issue is related to PUP-9997, but I think the key observation is Josh's from a few comments back: that it is inappropriate for the Exec provider to default the cwd parameter. Instead, if no value is specified for that parameter then the provider ought not to attempt to change directory at all, neither in the parent nor in the child. Such a change should be pretty safe from unwanted side effects, for in the vast majority of cases, changing the working directory to the same directory it already is, as Puppet does now, will have the same observable effects as the proposed behavior of not changing it at all. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.129594.1570194660121%40Atlassian.JIRA.
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title
John Bollinger commented on PUP-10080
Re: Exec resources fail if the working directory is inaccessible
Huh. Do you reproduce example 1 with unmodified Puppet, Josh Cooper? Because when I hit the facter issue, it seems like puppet doesn't go anywhere at all – even puppet help fails – yet under Example 1 circumstances (the working directory exists but is inaccessible) an Exec with cwd set applies successfully for me. That would be Example 3
Set up as in Example 1
Execute the command
puppet apply --execute "exec { '/bin/echo': cwd => '/tmp' }"
The catalog is compiled and applied successfully in that case.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title
John Bollinger commented on PUP-10080
Re: Exec resources fail if the working directory is inaccessible
Trace of example 1:
# puppet apply --trace --execute "exec { '/bin/echo': }"
Notice: Compiled catalog for moby.stjude.org in environment production in 0.04 seconds
Error: Working directory /mnt/auto/home/miller2grp/jbolling does not exist!
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/execution.rb:196:in `execute'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec.rb:60:in `block in run'
/opt/puppetlabs/puppet/lib/ruby/2.5.0/timeout.rb:93:in `block in timeout'
/opt/puppetlabs/puppet/lib/ruby/2.5.0/timeout.rb:103:in `timeout'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec.rb:53:in `run'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec/posix.rb:45:in `run'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:133:in `block in sync'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:130:in `times'
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title John Bollinger commented on PUP-10080 Re: Exec resources fail if the working directory is inaccessible FACT-2055 created for the Facter side. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.327890.1570115712000.128396.1570129260821%40Atlassian.JIRA.
Jira (FACT-2055) Facter fails if its working directory does not exist
Title: Message Title John Bollinger created an issue Facter / FACT-2055 Facter fails if its working directory does not exist Issue Type: Bug Affects Versions: FACT 3.14.3 Assignee: Unassigned Components: CLI Created: 2019/10/03 12:00 PM Priority: Minor Reporter: John Bollinger Originally reported as part of PUP-10080: puppet fails if its working directory does not exist. Josh Cooper attributes the failure to Facter, and indeed, the standalone facter executable seems to exhibit related behavior. All puppet faces seem to be affected, including those that have no plausible need for working-directory access, such as puppet help. Facter does not exhibit such a failure when the working directory exists but is inaccessible to it. Expected behavior When its working directory does not exist, facter should nevertheless run successfully and evaluate and report all the facts it can do. This should happen for both the standalone executable and for the Puppet-integrated version. Observed behavior Facter crashes immediately when its working directory does not exist. For the puppet-integrated version, this crashes the whole puppet process. To reproduce 1. Create a fresh directory for the experiment: mkdir doomed. 2. Make that directory the working directory: cd doomed. 3. In a separate shell, remove the directory: rm doomed. 4. In the first shell, run facter or any Puppet command at all, for example facter
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10080
Exec resources fail if the working directory is inaccessible
Change By:
John Bollinger
*Puppet Version:* 6.8.1 *Puppet Server Version:* 6.5.0 *OS Name/Version:* CentOS 7Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist.I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I {{sudo}} a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple {{Exec}} resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the {{Exec}} should fail.*Desired Behavior:*{{Exec}} resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the {{cwd}} parameter.Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason.*Actual Behavior:*{{Exec}} resources with no {{cwd}} spuriously specified fail spuriously when Puppet's working directory cannot be accessed, even when execution of the command does not depend on accessing that directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with {{puppet apply}}, too, like so:*Example 1*1. log in to a machine on which my home directory is on an automounted NFS file system with root squashing in effect 2. {{sudo bash}} to obtain a root shell 3. Execute{code:shell}puppet apply --execute "exec { '/bin/echo': }"{code}*_Output:_*{quote}Notice: Compiled catalog for xxx.yyy.zzz in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/a_group/jbolling does not exist! Error: /Stage[main]/Main/Exec[/bin/echo]/returns: change from 'notrun' to ['0'] failed: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! Notice: Applied catalog in 0.12 seconds{quote}Errors of the same form are also reported by the agent under these circumstances if the catalog being applied contains `Exec` resources without {{cwd}} parameters. On the other hand, these particular failures do not occur if the {{Exec}} in question has a {{cwd}} parameter designating an existing, accessible directory, notwithstanding that the Puppet process's own working directory is inaccessible to it.Oddly enough, a different failure occurs if Puppet's working directory actually doesn't exist. That
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10080
Exec resources fail if the working directory is inaccessible
Change By:
John Bollinger
*Puppet Version:* 6.8.1 *Puppet Server Version:* 6.5.0 *OS Name/Version:* CentOS 7Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist.I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I {{sudo}} a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple {{Exec}} resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the {{Exec}} should fail.*Desired Behavior:*{{Exec}} resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the {{cwd}} parameter.Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason.*Actual Behavior:*{{Exec}} resources with no {{cwd}} spuriously fail when the Puppet's working directory cannot be accessed, even when no particular working directory is specified, and even when execution of the command does not depend on accessing the working that directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with {{puppet apply}}, too, like so:*Example 1*1. log in to a machine on which my home directory is on an automounted NFS file system with root squashing in effect 2. {{sudo bash}} to obtain a root shell 3. Execute{code:shell}puppet apply --execute "exec { '/bin/echo': }"{code}*_Output:_*{quote}Notice: Compiled catalog for xxx.yyy.zzz in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/a_group/jbolling does not exist! Error: /Stage[main]/Main/Exec[/bin/echo]/returns: change from 'notrun' to ['0'] failed: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! Notice: Applied catalog in 0.12 seconds{quote}Errors of the same form are also reported by the agent under these circumstances if the catalog being applied contains `Exec` resources without {{cwd}} parameters. On the other hand, these particular failures do not occur if the {{Exec}} in question has a {{cwd}} parameter designating an existing, accessible directory, notwithstanding that the Puppet process's own working directory is inaccessible to it.Oddly enough, a different failure
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10080
Exec resources fail if the working directory is inaccessible
Change By:
John Bollinger
*Puppet Version:* 6.8.1 *Puppet Server Version:* 6.5.0 *OS Name/Version:* CentOS 7Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist.I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I {{sudo}} a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple {{Exec}} resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the {{Exec}} should fail.*Desired Behavior:*{{Exec}} resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the {{cwd}} parameter.Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason.*Actual Behavior:*{{Exec}} resources spuriously fail when the working directory cannot be accessed, even when no particular working directory is specified, and even when execution of the command does not depend on accessing the working directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with {{puppet apply}}, too, like so:*Example 1*1. log in to a machine on which my home directory is on an automounted NFS file system with root squashing in effect 2. {{sudo bash}} to obtain a root shell 3. Execute{code:shell}puppet apply --execute "exec { '/bin/echo': }"{code}*_Output:_*{quote}Notice: Compiled catalog for moby xxx . stjude yyy . org zzz in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/ miller2grp a_group /jbolling does not exist! Error: /Stage[main]/Main/Exec[/bin/echo]/returns: change from 'notrun' to ['0'] failed: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! Notice: Applied catalog in 0.12 seconds{quote}Errors of the same form are also reported by the agent under these circumstances if the catalog being applied contains `Exec` resources without {{cwd}} parameters. On the other hand, these particular failures do not occur if the {{Exec}} in question has a {{cwd}} parameter designating an existing, accessible directory, notwithstanding that the Puppet process's own working directory is inaccessible to it.Oddly enough, a different failure occurs if
Jira (PUP-10080) Exec resources fail if the working directory is inaccessible
Title: Message Title John Bollinger created an issue Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible Issue Type: Bug Affects Versions: PUP 6.8.1 Assignee: Unassigned Components: Types and Providers, UX Created: 2019/10/03 8:15 AM Priority: Minor Reporter: John Bollinger Puppet Version: 6.8.1 Puppet Server Version: 6.5.0 OS Name/Version: CentOS 7 Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist. I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I sudo a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple Exec resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the Exec should fail. Desired Behavior: Exec resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the cwd parameter. Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason. Actual Behavior: Exec resources spuriously fail when the working directory cannot be accessed, even when no particular working directory is
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title John Bollinger commented on PUP-10018 Re: The module tool won't solve some dependencies without --force or --ignore-dependencies Hi Jorie Tappa, To the best of my knowledge, PDK does not address the problem of installing or upgrading modules in a working Puppet environment (the special case of the "pdk test unit" command notwithstanding). Perhaps I have used the wrong name. As the instructions for reproducing the issue show, I am talking about the "puppet module install" and especially "puppet module upgrade" commands. These do not emit deprecation warnings when run. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.324663.1568391367000.109794.1569260580289%40Atlassian.JIRA.
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10018
The module tool won't solve some dependencies without --force or --ignore-dependencies
Change By:
John Bollinger
*Puppet Version: 6.8.1* *Puppet Server Version: 6.5.0* *OS Name/Version: Red Hat Enterprise Linux Server 7.4*The module tool refuses to perform valid module upgrades under some circumstances, unless the {{\-\-force}} or {{\-\-ignore\-dependencies}} option is applied. Even {{\-\-ignore\-dependencies}} does not suffice in some cases. Specifically, it seems unwilling to perform an upgrade across a major version of the specified module if that requires an upgrade even of the minor version of one of that module's dependencies. Alternatively, the tool's objection might be to performing a set of upgrades that are valid as a group, but which cannot be broken down into a sequence of separate, individually-valid upgrades.The particular case in which I experienced this can be reproduced like so: # Start with a clean install of Puppet 6.8.1 and puppetserver 6.5.0 (I used the Puppet, Inc. RPMs, installed via yum). # Install version 6.3.0 of puppetlabs-apt via the module tool # Install version 2.1.2 of puppetlabs-puppet_agent via the module tool # Attempt to upgrade puppetlabs-puppet_agent to version 2.2.0 via the module tool (fails on unresolvable dependencies) # Attempt to upgrade puppetlabs-apt to version 7.1.0 via the module tool (fails on unresolvable dependencies)One should not need to use {{\-\-force}} or {{\-\-ignore\-dependencies}} to upgrade from one set of module versions in which all dependencies are satisfied to another set of module versions in which all dependencies are satisfied.*Desired Behavior:*The module tool should be willing to perform upgrades such as those described without using {{\-\-force}} or {{\-\-ignore\-dependencies}}. In particular, it should be willing to perform any combination of minor-version upgrades in service to an upgrade of the module named on the command line, so long as it results in a final state in which all dependencies are satisfied. Use of {{\-\-force}} or {{\-\-ignore\-dependencies}} is not desirable here because it does not automatically solve dependencies, and it can (and often does) produce a situation in which dependencies indeed are not fully satisfied.It would be acceptable, albeit not ideal for this purpose, to require use of a new, different command-line argument.*Actual Behavior:*Here's an example of the observed behavior. Specific module versions are expressed via {{\-\-version}} options to ensure reproducibility. The target versions for the upgrade commands reflect the latest versions of the modules involved as of the time of this report, and at this time, the upgrade failures can also be reproduced without specifying target module versions._*Preparing the environment ...*_{{# puppet module list}} {{/etc/puppetlabs/code/environments/production/modules (no modules installed)}} {{/etc/puppetlabs/code/modules (no modules installed)}}
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10018
The module tool won't solve some dependencies without --force or --ignore-dependencies
Change By:
John Bollinger
*Puppet Version: 6.8.1* *Puppet Server Version: 6.5.0* *OS Name/Version: Red Hat Enterprise Linux Server 7.4*The module tool refuses to perform valid module upgrades under some circumstances, unless the {{\-\-force}} or {{\-\-ignore\-dependencies}} option is applied. Even {{\-\-ignore\-dependencies}} does not suffice in some cases. Specifically, it seems unwilling to perform an upgrade across a major version of the specified module if that requires an upgrade even of the minor version of one of that module's dependencies. Alternatively, the tool's objection might be to performing a set of upgrades that are valid as a group, but which cannot be broken down into a sequence of separate, individually-valid upgrades.The particular case in which I experienced this can be reproduced like so: # Start with a clean install of Puppet 6.8.1 and puppetserver 6.5.0 (I used the Puppet, Inc . RPMs, installed via yum). # Install version 6.3.0 of puppetlabs-apt via the module tool # Install version 2.1.2 of puppetlabs-puppet_agent via the module tool # Attempt to upgrade puppetlabs-puppet_agent to version 2.2.0 via the module tool (fails on unresolvable dependencies) # Attempt to upgrade puppetlabs-apt to version 7.1.0 via the module tool (fails on unresolvable dependencies)One should not need to use {{\-\-force}} or {{\-\-ignore\-dependencies}} to upgrade from one set of module versions in which all dependencies are satisfied to another set of module versions in which all dependencies are satisfied.*Desired Behavior:*The module tool should be willing to perform upgrades such as those described without using {{\-\-force}} or {{\-\-ignore\-dependencies}}. In particular, it should be willing to perform any combination of minor-version upgrades in service to an upgrade of the module named on the command line, so long as it results in a final state in which all dependencies are satisfied. Use of {{\-\-force}} or {{\-\-ignore\-dependencies}} is not desirable here because it does not automatically solve dependencies, and it can (and often does) produce a situation in which dependencies indeed are not fully satisfied.It would be acceptable, albeit not ideal for this purpose, to require use of a new, different command-line argument.*Actual Behavior:*Here's an example of the observed behavior. Specific module versions are expressed via {{\-\-version}} options to ensure reproducibility. The target versions for the upgrade commands reflect the latest versions of the modules involved as of the time of this report, and at this time, the upgrade failures can be reproduced without specifying target module versions._*Preparing the environment ...*_{{# puppet module list}} {{/etc/puppetlabs/code/environments/production/modules (no modules installed)}} {{/etc/puppetlabs/code/modules (no modules installed)}}
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10018
The module tool won't solve some dependencies without --force or --ignore-dependencies
Change By:
John Bollinger
*Puppet Version: 6.8.1* *Puppet Server Version: 6.5.0* *OS Name/Version: Red Hat Enterprise Linux Server 7.4*The module tool refuses to perform valid module upgrades under some circumstances, unless the {{\-\-force}} or {{\-\-ignore\-dependencies}} option is applied. Even {{\-\-ignore\-dependencies}} does not suffice in some cases. Specifically, it seems unwilling to perform an upgrade across a major version of the specified module if that requires an upgrade even of the minor version of one of that module's dependencies. Alternatively, the tool's objection might be to performing a set of upgrades that are valid as a group, but which cannot be broken down into a sequence of separate, individually-valid upgrades.The particular case in which I experienced this can be reproduced like so: # Start with a clean install of Puppet and puppetserver version 6.8.1 and puppetserver 6 . 5.0. # Install version 6.3.0 of puppetlabs-apt via the module tool # Install version 2.1.2 of puppetlabs-puppet_agent via the module tool # Attempt to upgrade puppetlabs-puppet_agent to version 2.2.0 via the module tool (fails on unresolvable dependencies) # Attempt to upgrade puppetlabs-apt to version 7.1.0 via the module tool (fails on unresolvable dependencies)One should not need to use {{\-\-force}} or {{\-\-ignore\-dependencies}} to upgrade from one set of module versions in which all dependencies are satisfied to another set of module versions in which all dependencies are satisfied.*Desired Behavior:*The module tool should be willing to perform upgrades such as those described without using {{\-\-force}} or {{\-\-ignore\-dependencies}}. In particular, it should be willing to perform any combination of minor-version upgrades in service to an upgrade of the module named on the command line, so long as it results in a final state in which all dependencies are satisfied. Use of {{\-\-force}} or {{\-\-ignore\-dependencies}} is not desirable here because it does not automatically solve dependencies, and it can (and often does) produce a situation in which dependencies indeed are not fully satisfied.It would be acceptable, albeit not ideal for this purpose, to require use of a new, different command-line argument.*Actual Behavior:*Here's an example of the observed behavior. Specific module versions are expressed via {{\-\-version}} options to ensure reproducibility. The target versions for the upgrade commands reflect the latest versions of the modules involved as of the time of this report, and at this time, the upgrade failures can be reproduced without specifying target module versions._*Preparing the environment ...*_{{# puppet module list}} {{/etc/puppetlabs/code/environments/production/modules (no modules installed)}} {{/etc/puppetlabs/code/modules (no modules installed)}} {{/opt/puppetlabs/puppet/modules (no modules
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10018
The module tool won't solve some dependencies without --force or --ignore-dependencies
Change By:
John Bollinger
*Puppet Version: 6.8.1* *Puppet Server Version: 6. 8 5 . 1 0 * *OS Name/Version: Red Hat Enterprise Linux Server 7.4*The module tool refuses to perform valid module upgrades under some circumstances, unless the {{\-\-force}} or {{\-\-ignore\-dependencies}} option is applied. Even {{\-\-ignore\-dependencies}} does not suffice in some cases. Specifically, it seems unwilling to perform an upgrade across a major version of the specified module if that requires an upgrade even of the minor version of one of that module's dependencies. Alternatively, the tool's objection might be to performing a set of upgrades that are valid as a group, but which cannot be broken down into a sequence of separate, individually-valid upgrades.The particular case in which I experienced this can be reproduced like so: # Start with a clean install of Puppet and puppetserver version 6.8.1. # Install version 6.3.0 of puppetlabs-apt via the module tool # Install version 2.1.2 of puppetlabs-puppet_agent via the module tool # Attempt to upgrade puppetlabs-puppet_agent to version 2.2.0 via the module tool (fails on unresolvable dependencies) # Attempt to upgrade puppetlabs-apt to version 7.1.0 via the module tool (fails on unresolvable dependencies)One should not need to use {{\-\-force}} or {{\-\-ignore\-dependencies}} to upgrade from one set of module versions in which all dependencies are satisfied to another set of module versions in which all dependencies are satisfied.*Desired Behavior:*The module tool should be willing to perform upgrades such as those described without using {{\-\-force}} or {{\-\-ignore\-dependencies}}. In particular, it should be willing to perform any combination of minor-version upgrades in service to an upgrade of the module named on the command line, so long as it results in a final state in which all dependencies are satisfied. Use of {{\-\-force}} or {{\-\-ignore\-dependencies}} is not desirable here because it does not automatically solve dependencies, and it can (and often does) produce a situation in which dependencies indeed are not fully satisfied.It would be acceptable, albeit not ideal for this purpose, to require use of a new, different command-line argument.*Actual Behavior:*Here's an example of the observed behavior. Specific module versions are expressed via {{\-\-version}} options to ensure reproducibility. The target versions for the upgrade commands reflect the latest versions of the modules involved as of the time of this report, and at this time, the upgrade failures can be reproduced without specifying target module versions._*Preparing the environment ...*_{{# puppet module list}} {{/etc/puppetlabs/code/environments/production/modules (no modules installed)}} {{/etc/puppetlabs/code/modules (no modules installed)}} {{/opt/puppetlabs/puppet/modules (no modules installed)}}{{# puppet
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title
John Bollinger updated an issue
Puppet / PUP-10018
The module tool won't solve some dependencies without --force or --ignore-dependencies
Change By:
John Bollinger
*Puppet Version: 6.8.1* *Puppet Server Version: 6.8.1* *OS Name/Version: Red Hat Enterprise Linux Server 7.4*The module tool refuses to perform valid module upgrades under some circumstances, unless the {{ \ - \ -force}} or {{ \ - \ -ignore \ -dependencies}} option is applied. Even {{ \ - \ -ignore \ -dependencies}} does not suffice in some cases. Specifically, it seems unwilling to perform an upgrade across a major version of the specified module if that requires an upgrade even of the minor version of one of that module's dependencies. Alternatively, the tool's objection might be to performing a set of upgrades that are valid as a group, but which cannot be broken down into a sequence of separate, individually-valid upgrades.The particular case in which I experienced this can be reproduced like so: # Start with a clean install of Puppet and puppetserver version 6.8.1. # Install version 6.3.0 of puppetlabs-apt via the module tool # Install version 2.1.2 of puppetlabs-puppet_agent via the module tool # Attempt to upgrade puppetlabs-puppet_agent to version 2.2.0 via the module tool (fails on unresolvable dependencies) # Attempt to upgrade puppetlabs-apt to version 7.1.0 via the module tool (fails on unresolvable dependencies)One should not need to use {{ \ - \ -force}} or {{ \ - \ -ignore \ -dependencies}} to upgrade from one set of module versions in which all dependencies are satisfied to another set of module versions in which all dependencies are satisfied.*Desired Behavior:*The module tool should be willing to perform upgrades such as those described without using {{ \ - \ -force}} or {{ \ - \ -ignore \ -dependencies}}. In particular, it should be willing to perform any combination of minor-version upgrades in service to an upgrade of the module named on the command line, so long as it results in a final state in which all dependencies are satisfied. Use of {{ \ - \ -force}} or {{ \ - \ -ignore \ -dependencies}} is not desirable here because it does not automatically solve dependencies, and it can (and often does) produce a situation in which dependencies indeed are not fully satisfied.It would be acceptable, albeit not ideal for this purpose, to require use of a new, different command-line argument.*Actual Behavior:*Here's an example of the observed behavior. Specific module versions are expressed via {{ \ - \ -version}} options to ensure reproducibility. The target versions for the upgrade commands reflect the latest versions of the modules involved as of the time of this report, and at this time, the upgrade failures can be reproduced without specifying target module versions._*Preparing the environment ...*_{{# puppet module list}} {{/etc/puppetlabs/code/environments/production/modules (no modules installed)}} {{/etc/puppetlabs/code/modules (no modules installed)}}
Jira (PUP-10018) The module tool won't solve some dependencies without --force or --ignore-dependencies
Title: Message Title John Bollinger created an issue Puppet / PUP-10018 The module tool won't solve some dependencies without --force or --ignore-dependencies Issue Type: Bug Affects Versions: PUP 6.8.1 Assignee: Unassigned Components: PMT Created: 2019/09/13 9:16 AM Priority: Normal Reporter: John Bollinger Puppet Version: 6.8.1 Puppet Server Version: 6.8.1 OS Name/Version: Red Hat Enterprise Linux Server 7.4 The module tool refuses to perform valid module upgrades under some circumstances, unless the -force or ignore-dependencies option is applied. Even -ignore-dependencies does not suffice in some cases. Specifically, it seems unwilling to perform an upgrade across a major version of the specified module if that requires an upgrade even of the minor version of one of that module's dependencies. Alternatively, the tool's objection might be to performing a set of upgrades that are valid as a group, but which cannot be broken down into a sequence of separate, individually-valid upgrades. The particular case in which I experienced this can be reproduced like so: Start with a clean install of Puppet and puppetserver version 6.8.1. Install version 6.3.0 of puppetlabs-apt via the module tool Install version 2.1.2 of puppetlabs-puppet_agent via the module tool Attempt to upgrade puppetlabs-puppet_agent to version 2.2.0 via the module tool (fails on unresolvable dependencies) Attempt to upgrade puppetlabs-apt to
Jira (PUP-9211) Module paths with common root cause incorrect name location validation errors.
Title: Message Title John Bollinger commented on PUP-9211 Re: Module paths with common root cause incorrect name location validation errors. The problem appears twofold: Puppet apparently is performing its location test via a string comparison that is unaware of path syntax. That is, whereas the case in the issue description should be accepted, this similar module path probably should still trigger an error: ../tmp/test/modules:../tmp/test/modules/common In a bona fide error case such as the above, it would be much clearer to report the issue, once, as a problem with the module path (one module directory must not be nested inside another), instead of reporting name validation errors for all the classes and defined types within the nested module directory. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7307) Tidy should support 'purge' or update file resource
Title: Message Title John Bollinger commented on PUP-7307 Re: Tidy should support 'purge' or update file resource I just conceived a need for exactly this, and I would really love to see it make it into 5.5.1. I'm surprised it hasn't been requested before. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title John Bollinger commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax Having just stumbled across this issue, I'd like to add my voice, too, to Sean's et al. I can understand and appreciate the desire to get rid of exported and virtual resource syntax from a future version of the language, but the features they provide and the manner in which they provide them have turned out to be powerful, general, and useful. I wouldn't be too upset to see the somewhat arcane language syntax by which these features are presently provided be replaced by function calls – though that would be disruptive – but simply removing all the things you can do with them without adequate replacement would be a tremendous step backward. Among the features I think need to have continued support are the ability provided by virtual and exported resources to specify the identity (including type) and attributes of a resource while deferring any decision about whether to add it to the (or any) catalog; the ability provided by exported resources to externalize the identity and attributes of such deferred resources so that they are available for use in other nodes' catalogs; the ability provided by collectors and existing functions to selectively add deferred resources of both varieties to catalogs, including the use of search expressions to designate the resources to add; the ability provided by collectors of both types to specify resource relationships in terms of search expressions; the ability provided by collectors of both types to override attributes of resources specified via search expressions. with respect to all the above uses of search expressions, substantial independence of manifest evaluation order. As long as this area is under scrutiny, however, there are certainly aspects of the legacy system that would bear improvement. In particular, separating the diverse functions served by collectors from each other springs immediately to mind, as does improving the consistency of these features across plugin and defined types (see, for example, PUP-6014 ). Clarifying and/or allowing control over the the applicability of resource defaults to deferred resources would also be advantageous. I'm sure there are other opportunities.
Jira (PUP-3142) exec type should allow passing of arguments as an array rather than a string
Title: Message Title John Bollinger commented on PUP-3142 Re: exec type should allow passing of arguments as an array rather than a string I'm uncertain to which provider the OP refers when he says Exec passes the command string to the shell, since that's a provider-specific behavior. Of course, running the command via a shell is exactly what the shell provider should do. I suppose the OP is referring to the posix provider, whose whole purpose is to bypass the shell. Puppet currently implements that provider in a manner that seems to end up invoking Kernel.exec with the single-string form of the command, and, as recently came up on puppet-users, that sometimes results in the command being executed via a shell, contrary to documentation. That constitutes a bona fide bug, either in the implementation or in the docs. Inasmuch as bypassing the shell is supposed to be the distinguishing characteristic of the posix provider, I think it's hard to attribute the bug elsewhere. I therefore suggest elevating this issue to "bug" status. Indeed, the posix provider is in a bit of a bind here, because the command is Exec's namevar, and so (I think) it must be a string. But that provider's intended and documented behavior more or less requires the command to be presented as an array – the user must be responsible for word splitting, (non-)quoting, etc., because the shell is not supposed to be involved. If it were possible, I think it would be best to allow the command attribute to be given as an array, whose elements are ultimately passed as multiple individual arguments to Kernel.exec without interpretation (for the posix provider). Even then, a correct, single-element command array could yield the wrong behavior under unfavorable (and fairly unlikely) circumstances, but in almost all cases it would do the right thing. Other providers could handle array commands as appropriate for themselves – for example, the shell provider might joining elements with whitespace, or even with semicolons, and pass the result to the shell. Of course, an array for the resource title means something completely different, and perhaps that is an additional roadblock in the way of taking this approach. If making the command itself be an array is indeed not possible, then there needs to be some alternative way to provide arguments separately from the command string, such as the one proposed in this issue. The posix provider cannot work correctly without. Add Comment
Jira (PUP-5395) There's no way to set resolution_type when using data bindings
Title: Message Title John Bollinger commented on PUP-5395 Re: There's no way to set resolution_type when using data bindings Is it ok if we leave the hiera_xxx functions as they are since they have the style that implies that the user knows the data configuration? Instead users should use the lookup function where the lookup options from data files becomes the default if not given as an argument to lookup. If the lookup() function honors the lookup options specified in the data, then I would be satisfied for hiera() to not do so. I agree that it does not make sense for the behavior of the hiera_xxx() functions to change in any case, but I do still recommend that those functions be deprecated. If lookup() behaves as suggested then the hiera() function should be deprecated, too. Overall, this could be less surprising than altering hiera() to sometimes perform hash-merge or array lookups. If deprecation is too strong to be palatable at this time, then at minimum start strongly promoting use of lookup() and the in-data lookup options as superior practice, which it is. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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 (HI-118) There's no way to set resolution_type when using data bindings
Title: Message Title John Bollinger commented on HI-118 Re: There's no way to set resolution_type when using data bindings The proposed solution seems a win to me, but it also seems to be missing an opportunity to be an even bigger win. Going back to my May, 2014 comments: Bottom line: hiera_hash() and hiera_array() should both be deprecated in favor of a means to express the intended retrieval type directly in the data. The hiera() function, whether invoked from the DSL or internally by Puppet, should use that means to retrieve the data correctly. To put it another way, the problem stated in the title of this issue is only one aspect of a deeper problem, which I described in those earlier comments. Those comments seemed to be acknowledged and well received at the time. I really hope the whole problem can be solved, especially since a partial solution now greatly reduces the likelihood that a complete solution will ever be implemented. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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 (HI-118) There's no way to set resolution_type when using data bindings
Title: Message Title John Bollinger commented on HI-118 Re: There's no way to set resolution_type when using data bindings +1 for lookupoptions. This seems to be a viable way to define the lookup type on a per-item basis. Questions: Is it intended that a merge strategy being defined for a given key indicates that ordinary lookups for that key should employ merging (of the specified flavor)? The alternative would be that only hash-merge lookups that happen to be performed for the key, as requested by some other means, would employ the specified strategy. The details presented in the proposal seem specific to hash-valued items. Supposing that the answer to my previous question is "yes", is it intended or desirable that array lookup type can be specified this way as well (i.e. as if hiera_array() were used)? I think the proposal says that the lookupoptions::* keys are intended themselves to be looked up in the data hierarchy. What type of lookup is used for them? Does the facility they provide apply recursively? Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-4071) The File Type Should Provide Link Validation
Title: Message Title John Bollinger commented on PUP-4071 Re: The File Type Should Provide Link Validation As I remarked on the dev list, I'm ok with this suggestion except for the default value of the proposed parameter. It should default to false, for all the same reasons that symlinks should not unconditionally autorequire their targets. Moreover, I contest the assertion that autorequiring the target is the most expected action. It's not at all what I expect based on Puppet's current behavior, nor what I would expect based only on the nature of symlinks and the purpose of Puppet resource relationships. The fact that :false is even a viable value argues for it being the default value. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- 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-2748) require = Exec does not work
Title: Message Title
John Bollinger commented on an issue
Re: require = Exec does not work
You have a misapprehension. Applying a resource involves first checking whether (and in which ways) that resource is already in sync, and then performing whatever actions, if any, are needed to bring it into sync. Resources that are already in sync automatically succeed, an which case other resources that depend on them can be applied. That is what is happening in this case.
Specifically, an Exec uses its 'onlyif' parameter (and 'unless' and 'creates') to determine whether it is already in sync, not to determine whether the resource itself succeeds or fails. If an Exec has an 'onlyif' command that produces a false exit status, then the Exec is deemed already in sync, and therefore succeeds without any attempt at running its 'command'.
Given the Exec's command being '/bin/true' in the example code, the dependent Notify will always be applied, regardless of any 'onlyif', 'unless', or 'creates'. This is the expected behavior.
Add Comment
Puppet / PUP-2748
require = Exec does not work
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: {noformat} exec { test : path = /bin:/sbin:/usr/bin:/usr/sbin, command = ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1461) Exec resource not notified but onlyif check gets executed anyway
Title: Message Title John Bollinger updated an issue Puppet / PUP-1461 Exec resource not notified but onlyif check gets executed anyway Change By: John Bollinger Issue Type: Bug Improvement 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-1461) Exec resource not notified but onlyif check gets executed anyway
Title: Message Title
John Bollinger commented on an issue
Re: Exec resource not notified but onlyif check gets executed anyway
The bottom line is that the observed behavior is by design. The 'onlyif', 'unless', and 'creates' parameters of an Exec serve the purpose of determining whether that resource is already in sync at the beginning of the run. As such, 'onlyif' and 'unless', if given, are always run as part of applying an Exec resource. This is intentional.
As an entirely separate consideration, if an Exec has refreshonly = true, then syncing that Exec – if it should turn out to be needed – is a no-op. That is, the effect of refreshonly = true is approximately the same as the effect of specifying the erstwhile 'command' parameter as the 'refresh' parameter instead, combined with specifying the 'command' as '/bin/true'.
For what it's worth, I agree both that Peter described a different (but related) issue, and that the behavior Peter describes is surprising. That one might indeed be characterized as a bug, but this one is a feature/improvement request (though I am not persuaded that it would in fact constitute an improvement).
Add Comment
Puppet / PUP-1461
Exec resource not notified but onlyif check gets executed anyway
Please have a look at this simplified example. {code} class runtimevariation { # dummy file ressources that should represent # some real software deployment file { '/tmp/software-v1': ensure = present, }file { '/tmp/software-v2': ensure = present, }file { '/tmp/software-v3': ensure = present, } ...
Jira (PUP-2748) require = Exec does not work
Title: Message Title John Bollinger commented on an issue Re: require = Exec does not work It sounds like you've got it, but I'm not sure what you mean is not [...] quite right. I anyway suppose you're just remarking that it's different than you expected / hoped. Just in case, here's a summary of the sequence of events during resource application: First example: (a) the Exec's onlyif command is executed, yielding exit status 0 (true) – means the command needs to run to sync the resource; (b) the command is run, yielding exit status 0 (true) – means the resource is successfully applied; (c) the Notify is applied, generating a message in the Puppet log. Second example: (a) the Exec's onlyif command is executed, yielding nonzero exit status (false) – means the resource is already in the target state (therefore successfully applied) thus the command is not run; (b) the Notify is applied, generating a message in the Puppet log. Contrast with the same cases if the Exec's command were instead /bin/false: Alternate first example: (a) the Exec's onlyif command is executed, yielding exit status 0 (true) – means the command needs to run to sync the resource; (b) the command is run, yielding nonzero exit status (false) – means the resource fails; (c) the Notify is skipped because it requires a failed resource. Alternate second example: (a) the Exec's onlyif command is executed, yielding nonzero exit status (false) – means the resource is already in the target state (therefore successfully applied) thus the command is not run; (b) the Notify is applied, generating a message in the Puppet log. [Same as the original second example.] Add Comment Puppet / PUP-2748 require = Exec does not work Puppet 3.5.1 resources types File and Notify cannot successfully require an Exec. The File or Notified are
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
John Bollinger commented on an issue
Re: Exec checks should be turned into metaparameters
Felix Frank wrote:
My reasoning was that a Fact bases solution will likely remove resources conditionally
if $::my_custom_fact { package { foo: } }
so that such resources cannot be safely required by others. If I understand you correctly, your point is that the require value can depend on the fact value as well. That is true, albeit unwieldy.
My point is twofold:
yes, the require value and/or the entire dependent resource can be guarded by the fact as well, but also
in cases where there are dependencies to worry about, they usually need to be guarded that way.
Consider, for example, a standard package / configuration / service module, where the user wants to accommodate an alternative service instead of the standard one (maybe apache on one hand and nginx on the other). You need to either enable or disable the whole chain together – if nginx is already installed, say, it is not sufficient to avoid managing only Package['httpd'].
On the other hand, if you have a dependency between two resources where the second can tolerate the first being unsynced, then that dependency is either inaccurately modeled or unneeded altogether. The innaccurately modeled end is one place defined alternatives could help, for without something like them, some of those cases simply cannot be modeled well.
From a design perspective, it would be consistent to make it possible for the user to require such conditional resources and sync the dependent resources even if the condition of the dependency are not met.
Yes, there is room for users to shoot themselves in the foot.
So I do see potential in such a dangerous feature, at least as a design study. Of course, if we add this at any point in time, getting rid of it again would be quite painful (a Puppet 5 kind of retraction).
You are right: it could be implemented that way, and careful puppeteers could put it to use without shooting themselves in the foot much. It might be an interesting experiment if it could be done in a provisional way, maybe like the future parser has been.
Nevertheless, there are alternative ways to approach the issues that would channel users in more effective directions, that would avoid opening new avenues for module incompatibility, and that would put lower demands on support channels, at least in the long run. But maybe I'm peddling betamaxes.
So a much less dangerous compromise could be to forego the onlyif/unless equivalents for now and only go
Jira (PUP-1125) Exec checks should be turned into metaparameters
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 (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
John Bollinger commented on an issue
Re: Exec checks should be turned into metaparameters
If we had onlyif available for the file resource type, we could easily tell Puppet that we want the config files to be written only if the main application executable exists. That way, the directory stays empty if the repository hasn't been cloned into it yet; but if the application is there, Puppet will write its config files on the next run.
Ok.
This discussion has lead me to realize that Puppet already has a pretty good approximation of 'onlyif' for all resource types, with this syntax:
exec { 'onlyif_command': }
-
type { 'title': parameters }
That yields roughly Felix's behavior (3) because syncing the Exec will fail if the onlyif command does not return a success result, preventing Puppet from attempting to sync the other resource.
Alternatively, if you prefer something similar to Felix's behavior (2), then I think you can use this variation:
exec { '/bin/true': _onlyif_ = 'onlyif_command', noop = true }
-
type { 'title': parameters }
In that case, Puppet will detect the Exec as out of sync if the onlyif command succeeds, but it will not attempt to sync it because it is marked noop. Because the Exec is not synchronized, Puppet will not (should not) attempt to sync the other resource.
Would one of those serve your requirement adequately?
Add Comment
Puppet / PUP-1125
Exec checks should be turned into metaparameters
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
John Bollinger commented on an issue
Re: Exec checks should be turned into metaparameters
You cannot get an analog of Felix's option (1) by chaining in in Exec, however, nor in general can you implement groups of alternative resources, such as we discussed earlier, where one resource being in sync is sufficient for the whole group to be synchronized. For such purposes, I find myself imagining a variation on defined types. Consider this syntax:
define package_a_or_b disjunctive () {
package { 'A': ensure = 'latest' }
-
package { 'B': ensure = 'present', noop = true }
}
...
package_a_or_b { 'A unless B': }
An ordinary defined type attempts to ensure that all resources declared within are synchronized, and succeeds if that is achieved. The obscurely-named 'disjunctive' keyword would indicate a different behavior, wherein the define succeeds if any one or more of the resources declared within is or can be synchronized, and it only attempts to sync any resource if none of them are yet synchronized.
In the example code, an instance of the disjunctive 'package_a_or_b' type is in sync if Package['B'] is present on the system, or if Package['A'] is present and at the latest version. If neither, then Puppet will attempt to ensure the latest version of A installed, but in no case will it install or update Package['B'], because that package is declared with noop = true.
Although that would introduce a new keyword, it would be backwards compatible with the current DSL because nothing is currently allowed between defined name and parentheses / body. Disjunctive types would have the nice property that the resources within succeed or fail as a group, with all the attending benefits for declaring relationships, while still relying on Puppet resources as their building blocks, with all the benefits attending that. And judicious use of Exec resources within such a construct could yield everything that 'onlyif' and 'unless' metaparameters might do, and then some.
Add Comment
Puppet / PUP-1125
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters Is a custom fact (or even easier, an external fact) that much harder? And wouldn't an external fact allow for a more DRY approach, e.g. if the same conditional logic was needed in more than one place? I'm not trolling; I think I may be missing some pain point. Indeed, now that external facts are synchronized via plugin-sync, they provide an excellent alternative, almost as easy to create, and more general. And if so, that makes me wonder if we should work on alleviating that pain point, rather than working around it by adding metaparameters. The only functional aspect of any of this that cannot be addressed by facts is one that has not yet been raised: evaluating conditions at the time of the catalog run, in conjunction with syncing a specific resource, rather than beforehand. Beyond that it's on one hand a question of syntax, and on the other a question of the nature of the abstractions Puppet works with. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters Arguments beginning with a definition of what puppet is are not very constructive. Not only does that target move, but your operational model is not mine (hint: it only exists in your mind). Asserting some local notion of forward-looking purity of that vision just asks that we worship your ideal. Unless you have commit rights or otherwise speak for PL as a whole, I'm not on for that ride. Realize that this tool's workplace is often nasty, fiddly, and loaded with inconsistency (you know, like the whole rest of this world). That is nothing new. You won't have a sparkling clean feature set free from ugly beasts and burdens foisted from deep down in POSIX, et al. Theoretical correctness is a luxury and only maybe warrants a mention in passing, just as a reminder. Maybe we can get back to the question at hand now? It depends – are you feeling better now? If indeed the question that you want to discuss is the subject of this feature request, then one constructive way to proceed would be to give examples of how you could use the feature to make life better for you. Some of us call those use cases. They will help those who ultimately will decide the matter to determine whether to indeed implement the requested feature, or an alternative, or nothing at all, and if a new feature is implemented then the use cases will help guide its design. (my 2 cents...) Felix Frank outlined the three needs well enough to proceed. But the change is maybe large, so I can only echo the suggestion to have it work just as the exec metaparam. On the contrary, Felix outlined three mutually exclusive implementation alternatives, to which some of this discussion has been directed. It remains an open question which would be best, but it is by no means clear that the requested feature would be the best way to serve the perceived need in the first place (since the nature of the need itself is not clear). That is the threshold question, and I will not allow it to be swept under the rug if I can help it. Add Comment Puppet / PUP-1125
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters A usecase which I hit multiple times is be for the package type: Install Package A only if Package B ist not installed The Puppet operational model is Puppet evaluates the current state of the machine, it uses that and other information to construct a catalog describing the desired target state, and then it attempts to put the machine into the chosen state. If, as in the case presented, the desired target state depends on whether a given package is installed, then the model demands that that information should be fed in up front (via a custom fact). Often an even better solution is to put the uncertain piece of state – e.g. whether Package B is installed – under management. That is, the best policy with Puppet is frequently tell; don't ask. Particular circumstances may admit other alternatives. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters Yes, the current canonical way to solve the described use case are facts. That can become unwieldy if it affects lots of resources, though. (Facter 2 and structured data may mitigate this somewhat). A site with many such resources therein has bigger problems with its approach. I am not averse to Puppet implicitly channeling people toward practices that will ultimately be more effective for them. On the other hand, the feature would merely introduce yet another means of controlling when a resource is viable for management. Other such means currently include schedules and the noop metaparameter. Perhaps so, and on that basis I could perhaps accept the feature without too much complaint. But I don't think it adequately addresses the alternative package use case. Problems arise when other resources need to depend on one or both of the alternatives, for surely if Package A is not in sync and is prevented from being synchronized by a noop_if parameter, then resources that depend on it must not be synchronized either. What's really wanted for this case is a higher-level abstraction over the pair of packages as alternatives for each other. That would be a lot clearer, and, where appropriate, relationships could then be directed at the pair instead of at one or the other. In some specific Package cases, that can now be done with the new support for virtual packages. For other cases, I think I would be a lot happier with a generic way to express such alternative groups in the DSL than with a way to cobble them together implicitly at catalog application time. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters I know this feature has been requested multiple times, but I am deeply skeptical of it. The 'onlyif' and 'unless' parameters make sense for Exec because, along with 'creates', they provide the basis for determining whether the resource is in sync. There is no other basis for making such a determination, since Execs have only parameters, and no properties. It all hangs together in that case, with Exec representing ad hoc resources built directly out of commands. For other resource types, the general premise that resources are in sync when and only when all their properties are in sync is deeply ingrained in users, modules, docs, and the code itself. Modifying that pillar of Puppetdom cannot help but be disruptive, and certainly cannot be considered uncontroversial. Furthermore, as I am inclined to say from time to time on the user list, Puppet is not a script engine. That is not a limitation, it is a strength! I urge you to not slip in (more) scripting through the back door. Useful new features are great, but not when they weaken what Puppet already offers. Promoting 'onlyif' and 'unless' to metaparameters might be less disruptive if instead of the behavior they now have on Execs (for in-syncedness evaluation), they instead set conditions under which resource synchronization would fail. E.g. if an 'onlyif' command were declared, and it failed when executed during the catalog run, then the resource would fail. But then either many erstwhile perfectly good Execs would be broken, or else there would be a confusing difference in behavior between Execs and other resource types. I think it would be wise to collect some proposed use cases for the feature (any implementation flavor) to evaluate how those might best be served. I'm inclined to think that where Puppet's existing facilities are insufficient for those, there will be better directions to go than endowing more resource types with 'onlyif' and 'unless'. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters
Jira (HI-118) There's no way to set resolution_type when using data bindings
Title: Message Title John Bollinger commented on an issue Re: There's no way to set resolution_type when using data bindings When I thought a bit about this because of a question on puppet-users, I realized that it is not an issue that can be solved by a change to Puppet DSL or to the way Puppet uses Hiera internally. Whether a priority lookup, a hash-merge lookup, or an array lookup is wanted in a particular data-binding situation is not (or at least should not be) a function of the class. Rather, it is an aspect of the data themselves. That is, even if there were a way to express in a class definition that a particular parameter should be bound via a hash-merge lookup (for example), that would just turn the problem around on people who want to use a priority lookup for that parameter. And, wow, I just saw the broader implication: the same argument applies to any use of hiera_array() or hiera_hash(). The intended meaning of the data is part of the data definition, and looking it up via a different function than intended changes that meaning. Hiera (the YAML back end) does not have a mechanism to express this aspect of the data, so the data consumer is left to guess which of three functions is the appropriate one to use for retrieval, without even a means to check after the fact whether they guessed right. Bottom line: hiera_hash() and hiera_array() should both be deprecated in favor of a means to express the intended retrieval type directly in the data. The hiera() function, whether invoked from the DSL or internally by Puppet, should use that means to retrieve the data correctly. Add Comment Hiera / HI-118 There's no way to set resolution_type when using data bindings Because it's the responsibility of the caller to set `resolution_type` in hiera, and there is no explicit caller when using data bindings, there's no way to tell hiera to use the array (append) or hash
Jira (PUP-2158) Directory Environments breaks many classic Config File Environments
Title: Message Title
John Bollinger commented on an issue
Re: Directory Environments breaks many classic Config File Environments
So if environmentpath is non-empty, then manifest, manifestdir and modulepath settings will be ignored. Whereas if environmentpath is empty, then the presence of directory environments on disk will be ignored, except to the extent to which a puppet.conf manifest or modulepath setting directly points to them (either statically or dynamically). The point is, they shouldn't interfere with one another.
Why? Specifically, why does $environmentpath need to have feature flag behavior? Is it not sufficient just to make it default to empty? Moreover, if $environment path can cause the $manifest, $manifestdir, and $modulepath settings be ignored, then doesn't that in itself defeat the objective that directory environments and dynamic environments not interfere? Mutual exclusion is a far cry from non-interference. Or is the description just poorly worded?
The directory environment docs indicate that Puppet falls back to dynamic environments if no static environment block and no directory environment is found for the target environment, and ultimately (though I don't see how it's actually separate) to the global settings. This seems logical, desirable, and possible, yet not consistent with the description of the proposed fix for this issue.
Add Comment
Puppet / PUP-2158
Directory Environments breaks many classic Config File Environments
If you use the script in the classic blog post http://puppetlabs.com/blog/git-workflow-and-puppet-environments you have Config File Environments located at /etc/puppet/environments. Unfortunately, Puppet 3.5.0 will treat them as Directory Environments. If you have a modulepath such as this: {noformat} modulepath=/etc/puppet/environments/$environme...
Jira (PUP-2158) Directory Environments breaks many classic Config File Environments
Title: Message Title John Bollinger commented on an issue Re: Directory Environments breaks many classic Config File Environments And I'm looking at changing the switch now to simply exclude or include the directory environment loaders based on the environmentpath setting, so that the underlying old environment behavior would always be there, but directory environments could be switched on in configuration. That sounds not only wiser but also easier to me. Do you even need to go that far, though? Consider the behavior if the default is an empty environment path, and no environment path has explicitly been configured. A search for a directory environment must always fail (quickly) because there are no base directories in the path to check. Per the docs, environment lookup then falls back on dynamic environments, so the result is the same as if the directory environment code is never consulted at all. Unless the environment resolution has other bugs, there should literally be no need for any change vs. 3.5.0 except the default value of the environment path. (And appropriate tests.) There is still the potential for overlapping configuration between dynamic/directory environments, but one would have to explicitly configure that in this case. Yes, but I don't see any way to avoid that and still provide the documented behavior. Add Comment Puppet / PUP-2158 Directory Environments breaks many classic Config File Environments If you use the script in the classic blog post http://puppetlabs.com/blog/git-workflow-and-puppet-environments you have Config File Environments located at /etc/puppet/environments. Unfortunately, Puppet 3.5.0 will treat them as
